Bitcoin Forum

I am familiar with using bitaddress.org to generate addresses. I am not sure how the random numbers are generated.

If I want to use dice to tediously generate a 260 bit random number, how can I use that random number to generate a private key / public address?

I have no programming expertise. Thanks!!

Just about any random 256-bit number constitutes a valid private key.  All you need to do, then, is calculate the bitcoin address for it.

https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses

Transform it to a 256bit Hex number and it is already the private key. Then use this to generate the public address: https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html

For safety, you should save the javascript and run it on an offline computer

I use four 16-sided dice from here: http://www.thediceshoponline.com/dice-search/D16
I use four different pretty colours and decide on their order in advance. Each throw gives me 16 bits. So eight such throws give you 128 bits, enough for an electrum wallet seed, while 16 throws give you 256 bits, which (pretty much always) make a private key.

If you don't have and don't want to buy 16-sided dice, but you have ordinary cubies lying around, you could, say, throw a pair of dice. If the first dice comes up 'm' and the second comes up 'n', work out 6*(m-1)+(n-1). If it's between 0 and 31, convert to binary and you have five bits. If it's between 32 and 35 you'd better throw again.

Once you have a dice-generated private key you will really HAVE to use a computer to get the public key from it. jl2012's link looks good, though it bears repeating that YOU MUST RUN IT OFFLINE. You may want to eat the computer afterwards to be absolutely sure.

Seems like such a waste of effort to have to keep throwing again every time the first die comes up 6 and the second comes up higher than 2.

Perhaps instead, throw one die 99 times

• or a pair of color coded dice 49 times, plus an additional throw of a single die
• or a color coded set of 3 dice 33 times
• or a color coded set of 4 dice 24 times, plus an additional throw of 3 dice
• or a color coded set of 5 dice 19 times, plus an additional throw of 4 dice
• or. . . (well, you get the point.  99 distinct ordered values from 6 sided dice)

Then you can subtract 1 from each value rolled and write it down as a 99 digit number in base 6.

Voila.  You've got yourself a private key with more than 255 bits of information.  Now you can convert the number to binary, or hex, or base58, or decimal, or however it is that you like to represent your private keys and use whatever method you prefer to calculate the public key.

Rather than trusting bitaddress, you could convert to WIF and then import the generated private key into Bitcoin-Qt running on an offline computer?  Then Bitcoin-Qt should calculate the address for you, right?

That's what I suggested somewhere else. Roll a 6 sided casino grade dice, about 100 times.

If you get a 1, write down 0.
If you get a 2, write down 1.
If you get a 3, write down 2.
If you get a 4, write down 3.
If you get a 5, write down 4.
If you get a 6, write down 5.

base6 number = 3315135445300124430102440020244024024200400400022442224420424444024020024240204 40440400202424020222

convert to base 16 = 8E85A30B4276949DBFBC8771EDC4BCF98B66785E68D22D162CE6E8D69D50819B

which is:
Private Key: L1zkkHQDDtQTDRtZQwJJxATFrDMTstGxMsKhxySaa4vqEFtwtnmd
Bitcoin Address: 16PYKf15c4kH7jYM4MTwQCgcmYuviLxGxB

You could also use 16 sided dice, there's one that's even called and labeled "hexadecimal dice".

http://www.mathartfun.com/shopsite_sc/store/html/HexaDie.jpg
http://www.dicecollector.net/JM/JM_d16.A.hex.jpg
http://www.gmdice.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/d/1/d16-hexidice-hexadecmal-dice.jpg

This 30-line Python script will do the hard work for you, and even give you easy-to-remember mnemonics! 
It even works on my Android phone (after getting Qpython from the Play Store.) You still need the dice, though :)

https://bitcointalk.org/index.php?topic=308972.0

example:

Not exactly the answer to the precise question, but what I did is to write up a "random file" containing data from /dev/random, hacking on the keyboard, and just a write-up of some dice rolls.  Any way you like, how many you like, just as it suits you.  Then hash the file with SHA256 to get the private key.

Another way to do this, for "perfect" entropy calculation is to roll six-sided dice and write down bits.  Then convert those directly to a private key.

If you roll:

1:  write down "00"
2:  write down "01"
3:  write down "10"
4:  write down "11"
5:  write down "0"
6:  write down "1"

Yes, you only get one bit when you roll a 5 or 6, two bits for everything else.  Stop when you have written down 128, 160, 192 or 256 bits (whatever your preference is).  If the dice rolls are perfectly random, so will your resulting binary string.

Bleah, I coded some python to turn any-sided dice into a full-strength private key, no hashes. The answer is it takes a LOT of dice rolling, less than 100 d6's is not a full-strength key.

I quit at an unencoded 64 byte hex key, you can convert it to an importable key/address with http://bitaddress.org or such.


Or if you want to see what it looks like with bits or coin flips:





Not a problem to roll that many dice if you've got a dice-o-matic (http://www.youtube.com/watch?v=7n8LNxGbZbs), though.

You know, since the OP talked about lack of experience in programming, there is a simplified method that works with just bitaddress.org

Roll the dice 100 times. Write down the sequence.

Example:

3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224

Then you use that as the brain wallet passphrase in bitaddress.org

Uncompressed
1JGHFyjsnyQHnW29ygv19Qz4p2WRQAqwcs
5KjcaDDnmNhSWG33bt6rQ9LeJyfE2mjrrGPbqbFwJj6ruPnHw2v

And if you want the compressed version, just copy the private key to the wallet details tab.

Compressed
12WQuVvxwbVz17NLjgUJJgwsw5BhgAbqkA
L5h61awSzrmVa9N2UxYq39ohgM5iWpUB2SvkmUCvhEpsFrDLCTVL

Easy. Works. Can not be brute forced. Make sure to roll the dice properly (roll it from far away and make it bounce against the other side.)

I approve of the "generate a shitload of entropy and hash it" method.  The reason I recommended my method is because it could be done with pen&paper, without any external functions.  You can actually get a full hex private key without touching any external scripts or figuring out how to securely/privately execute hashes.  Can be useful in some situations for people with nil programming experience.

But I also wasn't aware that many tools will do the hashing for you. 

 ;D I want one!  ;D

Some random dice rolls:

1515114655216115325642122225123253326422451141433346533141245222355351253322551 313634412352614264331
2443565212225612534555441166434331222244135565343252545521434253121562321443242 645511161421141542666
3625264632525323244536332552434513165352251263436321261524453551222433655626535 452245321333222534164
4141544241264462335153442225243422414232216646413144256143554416544246243141211 643563346263221443224
5361516555412114352626236336355256416333452441216245241432132543254145325513564 146253115163351263226
6314454446362462314626514444266211353522544624164642353465323155435124426666663 531545161262163664246

I like this one though:
http://pwgen-win.sourceforge.net/index.html

Anyway, it is not possible to derive the public key and the address without using using a computer

Anyway, it is not possible to derive the public key and the address without using using a computer
[/quote]

Sure.  But you're plugging it into an app that will generate that for you.  Not all apps will apply hashes for you. 

It is quite possible to do this with pen and paper.
I don't know the ripdem algorithm, but the sha and key multiplication could be done in a few hours of concentrated work(and a few hours on the next day to check). Nothing you want to do, but otherwise, if you can't trust any of your hardware, it could be the ultima ratio.

Before doing the calculation you may want to wrap the room and your head with tinfoil ;)

uh.. more like a few weeks. You can't do the work manually. It's too much. This has been discussed before. You would have to work non-stop for a few weeks straight, on the assumption that you can do several CORRECT calculations per minute, without breaks, and without sleep.

I know a drug that supposedly works to keep you awake, as coffee won't work after the first 72 hours. You will eventually need to rest, and then that doubles the time.

Plus, you want to double check that you finally got the correct address, so you'll want to do everything again after you're done.

For one bitcoin address.

Just use an offline computer.

No it can't be done manually. Jackjack explained it all in another thread where this came up. Search for it.

Anyway a lot of the heavy weights are in this thread. I would have thought that generating private keys manually might be termed a little extreme.

Depends on your definition of cost-to-benefit ratio:

Cost:  Spending 20 minutes, one time, to create entropy and convert it to a wallet
Benefit: Avoiding 100% of all BS regarding computer-generated entropy sources & algorithms, until the end of time

If you're holding a "lot" of money, some people would rather just remove all doubt.  And the cost of doing so really isn't that high.

Unfortunately I don't have that problem :p Got into bitcoin too late for that.

But will Bitcoin-QT import a private key directly? (not WIF) I am aware it has no checksum etc. Or would I need to rely on additional tools to ensure I generate the correct WIF key (example - bitcoin-bash-tools and bitaddress JS).




If I append "1", "2", "3" etc to the original series of rolls (seed) - sha256sum(3315135445366124436162446626244624624266466466622442224426424444624626624246264 4644646626242462622241) .. does this constitute a "secure" method for generating a series of addresses?



So, about 150 rolls of the dice?

Hello there

Note above. Would some one know if above method for generating private keys from a dice-generated seed be "secure" ?

What I would personally do is tack on a letter, say "x" and then use a 3 digit number with leading zeros.

For example:

3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x001
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x002
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x003

...

3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x998
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x999
3315135445366124436162446626244624624266466466622442224426424444624626624246264 464464662624246262224x000

Would give you a thousand addresses.

If it's just a few you need, I'd just roll another 100 times for every address. There is no need to roll more than that for each address, you'll be wasting rolls.

The dice rolls are secure as long as no one else is in the room, and no one else is watching you roll or can see the dice. The computer you use is secure as long as it is offline and is properly wiped or erased or encrypted or everything is run in RAM then completely powered off.

To "properly" roll the dice means you should throw it across the room, and record only the ones that bounce back from the opposite wall. (Or roll it on something similar to a craps table, where it has to bounce from the other side.)

If you're lazy and already have 100 dice, just throw them all at once against the wall and take a RAW picture of everything using a 24 megapixel DSLR camera at the highest ISO setting, then hash the 15 megabyte file for your new private key. Then delete the picture and format the memory card.

Welp, I have plugged away like a busy little beaver, and made a proper dice -> paper wallet app.


I wasn't content merely using dice as a base-6 number. I decided to remove any bias the cryptologists might find in your dice by randomly shuffling the rolls, bits, and hex characters, seeding urandom with your dice, and XORing the private key with system entropy. It's probably idiot-safe even if you just bang on the numberpad.

There's an undocumented feature for testing. At any point when inputting dice, you can put in a special letter to let the computer complete the rest of the dice rolls for you. "g"-generate random dice rolls; "z" - generate rolls of 1; "m" - generate the highest dice rolls possible.

I could maybe make this save the paper wallet info to a file or print at your command, or make Electrum seeds, if anybody even cares.

Addresses and such are calculated with the Python Bitcoin ECC library - https://bitcointalk.org/index.php?topic=271343.0

Download links:
http://we.lovebitco.in/dice2key.py (Python 2.7 source)
http://we.lovebitco.in/setup-dice2key.py (for py2exe)

http://we.lovebitco.in/dice2key.exe (Windows 32 bit executable (python 2.7.6/winxp))
md5: be686743bbe03ad8178c35f785e4c6fe *dice2key.exe

You shouldn't trust my exe, but there it is. I've not documented my exact build environment to make it reproducible.

So I am going to ask sort of an obvious question here, but maybe the answer isn't so obvious.  What is the right way to "roll" the die?  I was thinking of just dropping casino quality die from about 10cm above a hard surface.  Is this the best way?  Is there a best way?

I don't get this. The whole point of using dice was to bypass potentially compromised sources of randomness in our computers, no? Doesn't all that shuffing, seeding and XORing taint our pure dice-generated entropy?

There is a belief among some people that if you are rolling dice repeatedly many, many times, you can get into a bit of a rhythm such that you start to pick up the dice in almost exactly the same way, and release them in almost exactly the same way multiple times resulting in patterns in the results.

Personally, I suspect that this is generally unlikely, and if it is possible, it would be be unlikely that anyone could predict what your personal patterns would be.

However, if you want to be certain that you aren't accidentally creating predictable patterns in your rolls, I'd suggest placing multiple dice into a cup. cover the opening and give the cup a few firm shakes.  Then dump the dice out onto a flat surface.  The act of the dice bouncing off each other and the cylindrical sides of the cup should be sufficient to randomize the results even if you both drop them into the cup and shake it in exactly the same way every time.

If the input is random, then mixing it with the worst corrupted backdoored random source won't make it less random (as long as the functions are blind to the contents). If the input is not random, mixing it with a good random source will make it random.

A one-time pad is the perfect encryption, I'm using a one-time pad on your dice and throwing it away.

Before, the input was XORed with 0x00000000f (nothing), which reveals the dice rolls and any bias in them.

If your dice were heavier on the 1 side than the 6 side from the pips being drilled, then the "random" number would be biased in a way revealed by a randomness test suite (http://www.lavarnd.org/what/nist-test.html) over a statistically significant number of rolls. If I have 100 dice in a dice rolling machine, and die 33 is defective or a camera always reads it's bits incorrectly because a bug died on the lens, I've shuffled around that error and masked it.

Also there is the (non) issue of modulo bias when truncating a nonhex to hex-converted number. I let you type in more dice than required and use the extra bits, however, for non 2^x - sided dice, the number is "extremely slightly smaller than it should be".

Dice are not a quantum phenomena-based random source, and the mere act of putting different shaped ink on each side of a molecularly-perfect cube makes them imperfect physical objects.

Rolling dice is a paranoia level response to NSA backdoored random number generators, I'm just being more paranoid for you.

I've also extended the usefulness of your dice roll, you can continue to cut and paste the same dice into the program and not get identical results.

What taints true entropy is using a hash like sha256, or any other function that maps to a reduced set of bits. Previous hash functions have had successful reduction attacks demonstrated, there is no reason to assume that SHA2 is the perfect hash function.

I like your little app deepceleron. Works for me.

Bitaddress.org now also supports base6 dice-generated private keys:
https://bitcointalk.org/index.php?topic=43496.msg3586486#msg3586486

This is nice. The hex format can be confirmed with this I think -

echo 'obase=16; ibase=6; 0123450123450123450123450123450123450123450123450123450123450123450123450123450 12345012345012345012' | bc

A nice way to input dice throws directly into bitaddress and not have to rely on computer rng.


Separate question - can bitcoin-qt import base16 directly?

I tested this with a couple of hex keys and Bitcoin QT did not accept them.

Also, I posted about dice generated private keys at the bitaddress thread:
https://bitcointalk.org/index.php?topic=43496.msg3792411#msg3792411

I have been thinking about generating private keys, or even electrum seeds with dice, and came across some snags that maybe y'all can help me through.

Consider generating a 128 bit electrum seed using a six-sided die (it is more straightforward than generating private keys, because of the range of valid private keys required by secp256k1, but I think the discussion extends to private keys as well).

In order to ensure 128 bits of entropy, the sample-space for your dice-rolls must contain 2¹²⁸ or more elements.  Because the sample space of n dice rolls has 6ⁿ elements, and because 6⁴⁹ < 2¹²⁸ and 6⁵⁰ > 2¹²⁸, we say we need at least 50 six-sided dice rolls to generate 128 bits of entropy.

So how do you convert your 50 dice rolls into a 128 bit number?

One method mentioned in this thread is to treat your dice rolls as a 50-digit base 6 number, and just convert that number to base 2 (or hex).

The problem is not all 50-digit base 6 numbers convert to 128-digit base 2 numbers.  In fact, less than half of them do! This is because 2¹²⁸ / 6⁵⁰ ~ 0.421.

So what do you do if your 50-digit base 6 number converts to more than 128 base 2 digits?  Do you truncate the leading digits? The trailing digits?  Do you perform some other mapping to 128 digit numbers? Are you sure that your resulting set is uniformly distributed over the set of all possible 128 bit numbers?

The problem is worse with private keys, because 2²⁵⁶ / 6¹⁰⁰ ~ 0.177.

These kind of questions make me wonder how bitaddress.org is converting 99 dice rolls into private keys.  Even more concerning is that 6⁹⁹ < 2²⁵⁶!  ???

What seems far safer to me is do use some other methods mentioned in this thread:

• Disregard any base 6 number that is larger than your desired sample-space and re-roll (tedious)
• Hash your string of dice rolls.
• Use hex dice.

Regards,
Frito_Mosquito

You should read the rest of this thread, as everything you've typed is talked about.

I wrote something that you can type your dice (or anything) into, but it will only need 32 key presses and will be much stronger than the dice:
https://bitcointalk.org/index.php?topic=361092

This should end the "roll dice" talk.

I made it generate Electrum seeds with a 5 minute mod. Replace the end of the script with this "main" section:


Then run it and pick a seed.

eb3fd08cc9e5e8b84d6664df43869329
a26e94a535640cc9a3328d9623685959
312551f8084215516b09a721b00ee183
e6f9443810f3945142a52844f9d37678
74d7e7225cf22841ae2d4f7177eb1c10
ec51d3e933bdf6ac990fb611b8fb624a
9af6f28e6062f96f71866c6f7c39492f
d37411cfa6dc140bbd117376ac251312
b926a225f7a458e9d1d3d071c76cae68
e55d2eae738785407af71ca7229b9627
4cb4fcfbbc170131e7fe6fdea5fcd89f
4688605e91f5fb02cf6df254e78aaa59
6dca80cb9150f64b6b54ff078fcec946
f2adf8b925cf74d5e7c17af66853b136
238f2053f0031534e7a96a68c9963844
a653695ee91796e1a98427be2e619e6d
4098912769cd719929138edf7df12cca
5bbc479f71203c92495421ee258dad45
b9603f290a0d9cf071ee2d16ce26e65d
607ecf8b5128d1ae6ed032b809eec7de
ecc2fefa282fb169bc82f860d1dee5fc
bb8bdc8d8a8e8933842645884176066f
20d0011175644f13ca51d692f136323a
92152b46c9d5177372de0fa24cd95f05
d519871d0bacba9bd673f9eae7a7aeb2
e0510191d11e6af3ce3c45749b39fdc9
fcf7f4e0302d093ca0bd167d8051bb48
bb19bf51db6420f75fce755c001205fa
519d17f68c7220a31f8cb09c13ae1678
4eeb9f1a33e760d04a8cf1370e1410f9
37b00cf85895a689aa29151e06205a39
fe8082ec08890cc3c4df4a1bf2d35893
1c0fd63e8b75f8d8cae0d02eaa9ae1c3
2bdc23b5bf3d9f076ca1eb7051b09ac3
a3a783c06e1df0e269551f626ca696bf
909e8f72833416e036cfd29f43561fe2
43ca0039f9830c40e9067f3013db4ac2
2d54d817fb0e44e40e6874576eb17a8d
7caa7ecf06ca143a618203bd9798f6a4
3ef11dfded2c0079654f28ae83d15fac
7f7e266faef657ad7438c90ee882393c
67a069a5d418b0a20edfb276778ce570
179c6183113771710ae2d3d64c104870
2f01bf04723e908f8aee0de776c1f99b
6640898e7221f678881d6c0cba11fb9a
709a920233d6e50ea4f72c79ca761acc
e70dda0bb906d585ba05d68a8197d6ce
f1e29fc80907fb9657de73d0c92f3a5f
593fd8fcb423a0d3f8fd53d72a553044

I don't know why you'd use Electrum though, and have all your addresses rely on a number 340282366920938463463374607431768211456 times smaller than a Bitcoin private key.

I've asked a similar question at the bitaddress thread (https://bitcointalk.org/index.php?topic=43496.msg3792411#msg3792411). I too was concerned that 99 (6 sided) dice rolls would not give 256 bits of entropy. Casascius replied with this answer: https://bitcointalk.org/index.php?topic=43496.msg3798309#msg3798309

So 99 dice rolls give about 255.91 of entropy. That's not exactly 256 but enough for me to consider this to be safe.

Thanks.  This is clearly the practical solution to this problem.  I should have guessed that Casascius would have worked it out by now.

Similarly 49 six-sided dice rolls give 126.66 bits of entropy, which is still probably more than enough.

But I do think folks should be careful about blindly converting 100 digit base-6 numbers to private keys, for the reasons mentioned above.

Sorry.  I thought I read this thread fairly carefully, and did not see anyone mention the problems associated with 100-digit base 6 numbers that are > 2²⁵⁶.

Fortunately, maxmint has pointed me in the right direction.

If your dice roll information is truly random, I can't make it less random by scrambling it. The only drawback is that you can't independently verify that the exe isn't doing something nefarious unless you have source code.

You can simply comment out the four scrambling functions near the end of the source (surrounding rolls_to_hex64), and you will get the base6 decoding of your dice as output mod 2²⁵⁶ (hindsight: could have been mod(N-1) + 1).

I would recommend this address generator instead, if you want to type dice into it you can; just the time you take between entering dice rolls will be enough entropy:

https://bitcointalk.org/index.php?topic=361092.0