How to Create a Bitcoin Receive Address from a Coin Flip

[fasbit]

Step by Step Tutorial

• Create a Bitcoin address by flipping a coin in 4 easy steps
• Create a Bitcoin address so secret, {Insert name of your Government Spy agency Here} wont even know who made it!
  

Quick Intro
A Bitcoin private key is a really big number that is created in a very specific format¹.  Once the private key is created, it can then be pushed through a mathematical gauntlet and produce a Public Address that anyone can use to accept bitcoin payments.  Every Public Address corresponds to a Private Key and vice-versa.  If you could guess a private key, you could access and spend the Bitcoins stored at the address as if they were yours.  It is not likely that you or anyone else will ever guess a private key especially if it is created randomly. You can create your own private keys from scratch and do it randomly or you can let the wallet do it for you.  This tutorial is about creating a key safely and randomly. In the Bitcoin world, you don't actually "own" bitcoins.  What you do have in your wallet is a set of keys that allows you to do anything you want with the bitcoins assigned on the blockchain to that address.  That's it in simple form:  Private Keys unlock your access to the blockchain balance at a Bitcoin address. If you destroy the keys or the harddrive where they are stored, the Bitcoins will still be there on the blockchain.  You cannot "destroy" Bitcoins unless you destroy the entire blockchain.  Bitcoins live forever!

How to create a Bitcoin Private Key and therefore a Unique Public Address, by flipping a Coin.

Step A.
Get a coin.  Label one side as “1” and the other side as “0”
Flip the coin 256 times and record the results as you go in groups of 4.  When you are done, your binary sequence should look something like this:

Binary: (Below is four sequences of 64 bits each 4x64=256)
0010 1000 1000 1111 0011 1001 1011 1011 1111 1101 0011 0110 1101 1010 0101 1010
0001 0010 1101 0001 0110 0010 1100 1011 0001 1000 1001 0111 1100 1001 0000 0010
0010 1000 1000 1011 0011 1001 1011 1011 0011 0110 1101 1010 0101 1010 0001 0010
1101 0001 0110 0010 1100 1011 0001 1000 1001 0111 1100 1001 0000 0010 0011 1101

The grouping and spaces are not important. They are grouped this way to make them "Human Friendly."
One Technical Note:  There is an upper limit on the range of acceptable valid public keys.  If for some reason you randomly flip the coin and you get 127 "1"s in a row, you are approaching the upper limit! ²

Step B.
The next step is to convert the Binary to HEX. Finding a Binary to Hex converter on-line that will handle that sized number is no easy task.
mathsisfun.com – This one can handle 64 bits at a time. Just keep them in order and separate.  Do 64 bits at a time. (4 times)

The Binary Number above Converted to HEX: (32 bytes)
288F 39BB FD36 DA5A 12D1 62CB 1897 C902 288B 39BB 36DA 5A12 D162 CB18 97C9 023D
This HEX number is your Raw Private Key, and again the spacing is not important.
*** Note: If you owned a pair of 16 sided dice, you could roll the pair 32 times and record the results like above and save the coin tossing found in Step A. ***

Step C.
Next, Cut and paste the HEX number into Brainwallet and choose “HEX” to “B58Check.”  This will create a very large number that begins with a “5”. This number is your private key “Wallet Import Format”.

*** You cannot use the Brainwallet BIN to HEX converter if you space them out like I did, due to the fact that Brianwallet adds a “0” place holder to every 4 bit BIN sequence. e.g. “1111” converted to HEX is “F” but Brainwallet converts it as “0F.”   But if you get rid of the spaces and paste the entire sequence in at once, you can use the BIN to BASE58Check converter and skip the HEX conversion (Step B.) altogether. In other words, lining the ones and zeroes up like I did, makes it more human friendly, but it makes you do an extra step.***

The HEX above converted to B58Check WIF:
5J89cr5WGdvQWeeekN5ZGzuXVsWREbAYku6MDeUgrJTjX1ZHhCX

Step D.
Next copy the private key WIF code. Click “Generator” and paste the private key into the Private Key box.  This will create your new Public Address.

WIF Format above Converted to Bitcoin Public Address:
1Cwd7i5R6GM56njNhyyr7RRUYo6e1AMg9A

You have now created a Private Bitcoin Key and a Public Address from 256 coin flips!

EXTRA SECURITY:  Just in case you are worried about using the online generator, you can download the .zip file at the bottom of the page (off Brainwallet) and set the generator up on your computer.  You can run this program off-line with no Internet connection.  Also do not use random.org or any other online site to generate a crytographic keys.  Sites like this should only be used for educational purposes.

EXTRA SPEED:  You can go to random.org and flip four or eight coins a time.  The Polish Zloty works great because it has the shape of a 1 and a 0. The randomness of their service is top notch.  It is possible that someone working at random.org could guess you are using the service to generate bitcoin private keys. So only use this option for educational purposes.

EXTRA COINS:  The Brainwallet site is also set up to do 25 other coins in addition to Bitcoin.

EXTRA MATH:  If you want to manually convert the HEX private key to WIF format, see this article:  https://en.bitcoin.it/wiki/Wallet_import_format

EXTRA RANDOM:  It is scientifically plausible to detect bias in your coin or flip method (this is absurd, but possible). If you flip 1000's of these coins the exact same way and published the results, then possibly even a computer could read the data and find a pattern. So instead of flipping 1 coin 256 times, you could get 256 coins, all different if possible.  Then you flip half and your drinking buddy flips the other half, letting them land on as many different hard surfaces as possible in your house.  Record the results.  Then the only bias will be in your two methods of flipping,  but no one could ever crack your bias unless you publish the results with a large, sufficiently sized sampling pool.

If you follow these directions exactly and create a 256 bit binary number, you will have created a unique number, never known to mankind before and probably will never occur again!

How to Use the Address
Upgrade your Bitcoin wallet to the latest stable release “9.3”

Linux
“Bitcoind”
Add “-server” to your configuration file.
Make sure the wallet is “unlocked”
Run “./bitcoind -daemon”
After the wallet synchs run this command:

./bitcoind importprivkey "5yourveryveryveryverylongprivatekeystring" "label if you want one"

It will take about 3 or 4 minutes after you import the key.
During this time the wallet is searching the blockchain for transactions to this new address.

Online Wallets
Blockchain.info has an “Import Private Key” feature you can use to load the address to your on-line wallet if you have a wallet there.

Windows QT https://en.bitcoin.it/wiki/How_to_import_private_keys_v7%2B

More Detail Article on Importing Keys https://en.bitcoin.it/wiki/How_to_import_private_keys

Test
Send yourself a very small amount of BTC to the new address to test it before you use it.

To Do: Excel > Bitcoin Binary to Public Key
To Do: Script >  Bitcoin Binary to Public Key

A Warning About Warnings
Almost every post about importing private keys, will warn you about the "danger" of messing around with private keys. I will layout a 2 point maxim for you that will allow you to evaluate said warnings and your own actions regarding private keys:
1. If you self generate a private key - make sure your method is based on true randomness (i.e. use a coin, a pair of dice or a coin flipping service) Do not trust Key Generating sites, online or offline.
2. If you self generate a private key - make sure no one can learn about your methodology (If you use any type of assistance like "brainwallet", do it on an offline computer that is always offline, and just use them for the easy math parts like converting large numbers between formats)
If you follow these 2 rules, you will have a safe private key.

[1713988583]

1713988583

[1713988583]

1713988583

[1713988583]

1713988583

[coinableS]

Awesome tutorial! I like using dice, but this would be a fun project as well, thanks for taking the time to put this together.

[fasbit]

Thanx!  Im working on the excel spreadsheet now.  Hope to have it out there shortly.

[Arnab biswas]

very helpful tutorial thankz for explaining it....really a good work

[NewLiberty]

I've a bunch of these left over from when I was running around to all the conventions....


So they are for sale.  If folks want them let me know and I will put some up for sale.
The folks that made them aren't doing it any more so to get more I would have to make a very large order.

[newIndia]

There was another discussion going on regarding this, where someone posted the following...

What does 'manually' mean, pen and paper only?

Pen and paper, calculator etc...

As long as it's not made by an application.

Pen and paper would take days.

http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html
This is ONE of the hashing algorithms (SHA-256) and this man says he could do 0.67 hashes per day.

The process of generating a bitcoin address by hand (pen and paper) would be the following.

1. roll a 6 sided dice 99 times.
2. write down each result, writing a "0" for every 6 that comes up.
3. take this long string of numbers from 0-5 and convert it from base 6 to base 10.
   a. This means starting from the first non-zero digit on the left, multiply it by 6 then add it to the next digit, then multiply by 6 then add to the next digit... etc. until you get a long number with digits from 0-9.
4. Now you will have to calculate the public key. This is more easily done if the private key (the long number you made) is in binary form (1 or 0) so convert the number to binary.
5. Use the ECDSA point doubling formula and point addition formula on the generator point to get the public key. This will probably take a few days.
6. Convert the public point's x and y value both into binary. Pad each of them with 0s on the left hand side in case they're shorter than 256.
7. add 00000100 to the far left, then the padded x, then the padded y.
8. follow the video I linked above to perform a single SHA256 on the binary string created in #7
9. once you get the single 256 bit binary string... you must then perform the RIPEMD160 hash algorithm on it.
10. once you get the 160 bit length hash from it, add 00000000 to the far left of it... hold this string for later. We will do two things to it.
11. perform a SHA256 on the string from #10, then perform ANOTHER SHA256 on the result. (double SHA256)
12. take the 32 bits on the far left of the result from #11 and add it to the far right of the result from #10
13. For every 8 zeros on the far left of the result of #12, write down a number 1 on a piece of paper. Then convert the left over bits to base 58 as per the bitcoin base 58 specification (it's slightly disorienting if you're doing by hand, as 0 is represented by 1, 1 is represented by 2, 57 is represented by z etc...)
14. now you have your bitcoin address. To format your private key in the widely used WIF format, perform #10-#13 on the binary private key from #4... except instead of sticking 8 zeroes to the far left, add 10000000 to it instead.

Can someone please tell me where are the 5-9 of this happening in the OP ?

[andytoshi]

Please please please do not do this. The cryptosystem which Bitcoin keys and addresses are part of assumes for its security that its private keys are uniformly random numbers. Flipping coins by hand will definitely not give uniformly random numbers, and is probably so biased (depending on your hand, the coin, what side you pick it up from, the surface it lands on, etc, etc) that you can measure it yourself by just flipping a coin and counting the zeroes and ones.

If you swap out one component of a cryptosystem for another you have constructed a new cryptosystem and need to argue its security. And I guarantee you won't find a good security argument for "Bitcoin script with biased randomness".

To add to the presumption of insecurity that should be applied to all new cryptosystems, let me point out that much of this one is gibberish:

Step by Step Tutorial

• Create a Bitcoin address by flipping a coin
• Create a Bitcoin address so secret, {Insert name of your Government Spy agency Here} wont even know who made it!
  

Linkage between addresses and identities has nothing to do with key generation. This sort of linkage is done by exploiting ordinary address mismanagement.

Simple Intro
A Bitcoin private key is a really big number that is created in a very specific format.

A Bitcoin private key is an integer modulo the field order of the secp256k1 curvegroup used by Bitcoin's signature scheme. It is an element of an additive group and has no size.

Once the private key is created, it can then be pushed through a mathematical gauntlet and produce a Public Address that anyone can freely give out without fear.

Publishing your addresses is a (potentially very serious) privacy risk and cannot be done "freely without fear".

Every Public Address corresponds to exactly one Private Key and vice-versa.

This is simply false.

If you could guess a private key, you could access and spend the Bitcoins stored at the address as if they were yours. It is not likely that you or anyone else will ever guess a private key.

"not likely" is an understatement. The probability is 2^{-160}. There is nothing in yourordinary life that is comparable to this number. Nobody, ever, will ever find a private key by guessing uniformly at random. (Of course, they may exploit biases in random number generators and guess nonuniformly at random; this has happened many times.)

You can however, create you own private keys from scratch or you can let the wallet do it for you.  Your option.

This is horrifically bad advice. Key management is hard enough to do when using software specifically designed to do it for you. Manual key management is stupid, and manual key generation is even stupider.

How to create a Bitcoin Private Key and therefore a Unique Public Address, by flipping a Coin.
Get a coin.  Label one side as “1” and the other side as “0”
Flip the coin a minimum of 256 times and record the results as you go in groups of 4.  When you are done, your binary sequence should look something like this:

Binary: (Below is four sequences of 64 bits each 4x64=256)
0010 1000 1000 1111 0011 1001 1011 1011 1111 1101 0011 0110  
1101 1010 0101 1010
0001 0010 1101 0001 0110 0010 1100 1011 0001 1000 1001 0111
1100 1001 0000 0010
0010 1000 1000 1011 0011 1001 1011 1011 0011 0110 1101 1010
0101 1010 0001 0010
1101 0001 0110 0010 1100 1011 0001 1000 1001 0111 1100 1001  
0000 0010 0011 1101

The number of flips equals the bitness of the encryption.

This statement is nonsensical. Besides, there is no encryption in Bitcoin.

256 flips  = 256 bit encryption.  The grouping and spaces are not important. They are grouped this way to make them "Human Friendly."

The next step is to convert the Binary to HEX. Finding a Binary to Hex converter on-line that will handle that sized number is no easy task.

http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html – This one can handle 64 bits at a time. Just keep them in order and separate.  Do 64 bits at a time. (4 times)

Every part of this tells me you should not be touching encoding or decoding systems, let alone cryptosystems. Please do not give cryptographic advice if you do not know what you are talking about. It is dangerous and therefore immoral. Do you also advise people how to do surgery on themselves and others? Do you tell them how to pilot aircraft? (Perhaps you are an expert on one or both of these things; then how would you like to see laymen giving such advice?)

The Binary Number above Converted to HEX: (32 bytes)
288F 39BB FD36 DA5A 12D1 62CB 1897 C902 288B 39BB 36DA 5A12 D162 CB18 97C9 023D
This HEX number is your Raw Private Key, and again the spacing is not important.

Next, Cut and paste the HEX number into https://brainwallet.github.io/#converter and choose “HEX” to “B58Check.”  This will create a very large number that begins with a “5”. This number is your private key “Wallet Import Format”.

Please don't advise people to use brainwallet. About half of the things on that site are implemented dangerously; I have good reason to believe this is deliberate because its creator it attempting to steal money from users of its compromised keys. One good reason is that none of the dangerous things are labeled as such (or better, removed) despite repeated admonishment from myself and others.

*** You cannot use the Brainwallet BIN to HEX converter due to the fact that Brianwallet adds a “0” place holder to every 4 bit sequence. e.g. “1111” converted to HEX is “F” but Brainwallet converts it as “0F” ***

The HEX above converted to B58Check WIF:
5J89cr5WGdvQWeeekN5ZGzuXVsWREbAYku6MDeUgrJTjX1ZHhCX

Next copy the private key WIF code. Click “Generator” and paste the private key into the Private Key box.  This will create your new Public Address.

WIF Format above Converted to Bitcoin Public Address:
1Cwd7i5R6GM56njNhyyr7RRUYo6e1AMg9A

You have now created a Private Bitcoin Key and a Public Address from 256 coin flips!

As I mentioned above, manual key management is stupid and dangerous. (I'm going to get a lot of flack from paper wallet users for this claim. Nonetheless I stand by it.)

EXTRA SECURITY:  Just in case you are worried about using the online generator, you can download the .zip file at the bottom of the page (off Brainwallet) and set the generator up on your computer.  You can run this program off-line with no Internet connection for extra security.

This provides no extra security. Can you clarify (for my understanding of psychology) why you would think it does?

EXTRA SPEED:  You can go to https://www.random.org/coins/?num=4&cur=60-pln.1zloty and flip four or eight coins a time.  The Polish Zloty works great because it has the shape of a 1 and a 0. The randomness of their service is top notch.

This is unbelievably bad advice. If you are being paid to do this, then I advise you to speak with a priest and take a serious look at the moral decisions you are making. In any case, please stop.

EXTRA COINS:  The Brainwallet site is also set up to do 25 other coins in addition to Bitcoin.

I'll just leave this here.

I'm going to stop now; the remainder was simply instructions on importing keys, and I've already discussed manual key management. I will also say, without justification (as I'm tired of repeating it, not because I have none) that web wallets, and blockchain.info in particular, are not a safe way to store Bitcoin keys, and I strongly advise anyone storing coins with such a service to move them out of there immediately.

[andytoshi]

Can someone please tell me where are the 5-9 of this happening in the OP ?

These are done by your wallet when you import the key generated by the OP's method.

[newIndia]

Can someone please tell me where are the 5-9 of this happening in the OP ?

These are done by your wallet when you import the key generated by the OP's method.

As I can see that you have disqualified blockchain.info as a reliable wallet. Would like to know the technical reason behind it. I am assuming the user is downloading the paper wallet from blockchain.info, so that he is still in control of his coins, even if the site goes down. AFAIK, their keys are encrypted too... so for a DB hack, private keys should not be stolen.

Moreover, do u think, if someone runs bitaddress.org offline (by downloading the zip from https://github.com/pointbiz/bitaddress.org) to generate addresses, that is a safe method with enough randomness ?

[coinableS]

Can someone please tell me where are the 5-9 of this happening in the OP ?

These are done by your wallet when you import the key generated by the OP's method.

Not exactly, you can't import a base 6 format key into your wallet. First you have to convert it from base 6 to WIF. In the OP the conversion is done using brainwallet, but they use a different method so the conversion method is different, they started with binary 1 and 0 and then convert to hex and then to WIF. With the dice method you have base 6 and then convert to WIF private key with the help of an app like bitaddress.

[unamis76]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

[Buziss]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

That is a 16-sided dice. You only need to roll it 64 times to get a 256-bit number.
On the other hand, with a normal 6-sided dice, you need to roll it 100 times.

[newIndia]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

That is a 16-sided dice. You only need to roll it 64 times to get a 256-bit number.
On the other hand, with a normal 6-sided dice, you need to roll it 100 times.

More the side... less the randomness.

[fasbit]

Please please please do not do this. The cryptosystem which Bitcoin keys and addresses are part of assumes for its security that its private keys are uniformly random numbers. Flipping coins by hand will definitely not give uniformly random numbers, and is probably so biased (depending on your hand, the coin, what side you pick it up from, the surface it lands on, etc, etc) that you can measure it yourself by just flipping a coin and counting the zeroes and ones.

If you swap out one component of a cryptosystem for another you have constructed a new cryptosystem and need to argue its security. And I guarantee you won't find a good security argument for "Bitcoin script with biased randomness".

Thanks for the feedback.  However this is not a technical paper on cryptography, it is simply a step by step method on "HOW" to create a private key.  Most of your argument is either technical or addresses a "WHY" issue.  I did clean up two small issues that were over simplifications on my part.  

I will only address your central theme with which I disagree:  While it may be scientifically possible to determine that a coin flip method has a bias (you could make the same argument about dice as well), I could also make the same argument about how the Bitcoin client chooses its random string.  There are many examples of Bitcoin wallets themselves having built in biases that allowed the private keys to be hacked.  Computers have a built in bias against randomization which must be overcome.  Your Bitcoin wallet is no exception as it always sits on an OS.  (Google:  Android OS pseudorandom number generator PRNG - and also NSA Dual EC DRBG)

I offered an option in the original post where one could obtain true random numbers from a coin flip. > from www.random.org

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

Edit:  It is possible for someone at random.org to guess your intent, even though their site is not a BITCOIN related site.  So just use it for testing.  True security will come from the coin toss not an online web site.

[NewLiberty]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

These are 16 sided hexidecimal dice.
Despite Anditoshi's sage advice on much of the fluff around this method, using dice or coins is not significantly reduce or increaes the entropy of key generation.
It just isn't code+machine doing it.  Ultimately you are going to have to trust some device to use your bitcoin, but doing it by hand for novelty's sake is fun for some.

[NewLiberty]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

That is a 16-sided dice. You only need to roll it 64 times to get a 256-bit number.
On the other hand, with a normal 6-sided dice, you need to roll it 100 times.

More the side... less the randomness.

Why?
Are you assuming they are not balanced or something?

[fasbit]

I would be interested in buying a set of HEX dice... How much are they?

[swapcoiner]

Interesting. Reading for the first time creating bitcoin address with dices.

[unamis76]

NewLiberty, what kind of dice do you have there? How does it differ from normal dices/coin toss?

These are 16 sided hexidecimal dice.
Despite Anditoshi's sage advice on much of the fluff around this method, using dice or coins is not significantly reduce or increaes the entropy of key generation.
It just isn't code+machine doing it.  Ultimately you are going to have to trust some device to use your bitcoin, but doing it by hand for novelty's sake is fun for some.

Thank you for the clarification! And I'm also curious how much are those, if you're still selling

[gmaxwell]

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

LOL.  A "VERY SAFE" number which is trivially known to a third party.  Is someone at "random.org" paying you to encourage people to have them generate their private keys, or did you come by this cluelessness naturally?

I haven't looked recently but last I checked random.org methods were secret and not peer reviewed. So not only may the results be trivially maliciously logged (by the site operators or anyone whos compromised their system; or the operators of the VPSes they use (rackspace cloud)), they're probably more likely to be accidentally flawed because their methods are not reviewed.

[hexafraction]

*** You cannot use the Brainwallet BIN to HEX converter due to the fact that Brianwallet adds a “0” place holder to every 4 bit BIN sequence. e.g. “1111” converted to HEX is “F” but Brainwallet converts it as “0F” ***

Yes, you can. Just don't add spaces to the binary.

Also, don't use random.org at all. Use a physical coin, or a known-good physical RNG, preferably one that is designed to be unbiased, truly random using physical noise, and separate from a computer.

[R2D221]

Random.org is for trivial stuff.

Generating a Bitcoin private key and its corresponding address is not trivial at all.

[fasbit]

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

LOL.  A "VERY SAFE" number which is trivially known to a third party.  Is someone at "random.org" paying you to encourage people to have them generate their private keys, or did you come by this cluelessness naturally?

I haven't looked recently but last I checked random.org methods were secret and not peer reviewed. So not only may the results be trivially maliciously logged (by the site operators or anyone whos compromised their system; or the operators of the VPSes they use (rackspace cloud)), they're probably more likely to be accidentally flawed because their methods are not reviewed.

A. Attacking an idea or postulate is a great thing.  Attacking a person and calling them "clueless" is ad hominem and is below your status as a moderator of this board.
B. Random.org is peer reviewed here https://www.random.org/media As well as tested by third party orgs like http://www.ecogra.org/  Their methods are not secret but they are not public either.
C. So lets examine your logic:  Since random.org (peer reviewed, certified and in business since 1998) creates a buffer in advance full of billions of ones and zeroes and since it uses https, someone could log the front end usage of these ones and zeros after they leave the buffer and before they hit the https (side note on magnitude: these ones and zeroes from the buffer are used for ALOT of different applications on the site other than coin flips), track the usage by ip, collect and then echo the data once an ip pulls precisely 256 bits of data, run the bits through a key generator, (also try various combinations of the 256bit sequence like only look at the last 256 bits, since the first x bits could have been a test), create a database to collect all of these new bitcoin address and repeatedly query the entire blockchain to see if any of the addresses are extant. If any one address is extant and holds bitcoins, import the corresponding key into a wallet and steal the bitcoins.  OK... I will concede.  This may be possible. Its not likely considering the high level access, the subterfuge necessary, and the high number of bitcoin addresses to generate & query; not probable, but maybe possible.  

So to test your theory I am going to publish a bitcoin address that I created using random.org, leave some BTC there and see if they evaporate.  If they magically walk away, then we will know that someone at random.org is malicious.  If nothing happens, then Im going to stick with my "SAFE" comment.  I will however add a note of caution to the thread warning people that 1) They could get struck by lightning today 2) Earth could get destroyed by a meteor in the next 5 minutes AND 3) Somebody at random.org might guess your intent out of the millions of possible intents by those who use this service, parse through the data looking for precisely 256 bits of interesting target data turn them into a bitcoin key and steal your BTC.

Dear Mythical Hacker at Random.Org:  I created this address with the coin flip service on 02/07/2015.  I flipped 8 coins at once using Polish Zloties.  I pulled precisely 256 bits of data from the buffer to make it easy on you.  Please steal my bitcoins.
Here is the address: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA

[fasbit]

*** You cannot use the Brainwallet BIN to HEX converter due to the fact that Brianwallet adds a “0” place holder to every 4 bit BIN sequence. e.g. “1111” converted to HEX is “F” but Brainwallet converts it as “0F” ***

Yes, you can. Just don't add spaces to the binary.

Also, don't use random.org at all. Use a physical coin, or a known-good physical RNG, preferably one that is designed to be unbiased, truly random using physical noise, and separate from a computer.

Ahhh... you are correct!  I fixed the note.

[redsn0w]

Oh fantastic, thanks for the info. I surely will try!

[hhanh00]

This thread reminds me of [Calvin & Hobbes](http://www.gocomics.com/calvinandhobbes/2012/11/07)

[doof]

Please please please do not do this. The cryptosystem which Bitcoin keys and addresses are part of assumes for its security that its private keys are uniformly random numbers. Flipping coins by hand will definitely not give uniformly random numbers, and is probably so biased (depending on your hand, the coin, what side you pick it up from, the surface it lands on, etc, etc) that you can measure it yourself by just flipping a coin and counting the zeroes and ones.

If you swap out one component of a cryptosystem for another you have constructed a new cryptosystem and need to argue its security. And I guarantee you won't find a good security argument for "Bitcoin script with biased randomness".

To add to the presumption of insecurity that should be applied to all new cryptosystems, let me point out that much of this one is gibberish:

Every Public Address corresponds to exactly one Private Key and vice-versa.

This is simply false.

Are you talking about possible collisions?

[coinableS]

Please please please do not do this. The cryptosystem which Bitcoin keys and addresses are part of assumes for its security that its private keys are uniformly random numbers. Flipping coins by hand will definitely not give uniformly random numbers, and is probably so biased (depending on your hand, the coin, what side you pick it up from, the surface it lands on, etc, etc) that you can measure it yourself by just flipping a coin and counting the zeroes and ones.

If you swap out one component of a cryptosystem for another you have constructed a new cryptosystem and need to argue its security. And I guarantee you won't find a good security argument for "Bitcoin script with biased randomness".

To add to the presumption of insecurity that should be applied to all new cryptosystems, let me point out that much of this one is gibberish:

Every Public Address corresponds to exactly one Private Key and vice-versa.

This is simply false.

Are you talking about possible collisions?

I believe he is referring to this:  https://bitcointalk.org/index.php?topic=24268.0

So there are 2^160 public keys but only 2^96 private keys? Ho does that add up?
Are there private keys than unlock more than one public key?

There are just under 2^256 private keys, just under 2^256 public keys, and 2^160 addresses. There are some addresses that have more than one corresponding public key and thus more than one corresponding private key.

[coinpr0n]

Cool idea. So decentralized ...

[xDan]

It's a nice idea, but if you are doing coin flipping as a way to have "perfect" randomness, then you are rather spoiling the effort by having it touch any online computer system. I would rather just use bitcoin core on a linux livecd which I'd trust way more than any of the sites you linked.

i.e. suggesting mathisisfun.com website. Hey hackers, go compromise mathisfun.com, a fun little side project for you, maybe you'll find yourself some private keys.

Or maybe OP is the hacker who has already done so. Clever!

I would definitely be interested in seeing a tiny little script with no external dependencies that can be run on an offline system.

(Or excel/open office equations that I can copy+paste myself).

[fasbit]

It's a nice idea, but if you are doing coin flipping as a way to have "perfect" randomness, then you are rather spoiling the effort by having it touch any online computer system. I would rather just use bitcoin core on a linux livecd which I'd trust way more than any of the sites you linked.

i.e. suggesting mathisisfun.com website. Hey hackers, go compromise mathisfun.com, a fun little side project for you, maybe you'll find yourself some private keys.

Or maybe OP is the hacker who has already done so. Clever!

I would definitely be interested in seeing a tiny little script with no external dependencies that can be run on an offline system.

(Or excel/open office equations that I can copy+paste myself).

• I'm working on the excel.  I have the sha256 and base58 working in excel, just hung up on RIPEMD-160...but i'm close
• Also all of the links I suggested have "offline" capability.

[NewLiberty]

For the Hex Dice, I'd like to see them in happy homes:

BTC0.05 for a pair will get me off my butt to get them shipped to you in the USA, for international, probably a bit more.  Let me know where you are and I'll let you know how much more.

[spin]

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

LOL.  A "VERY SAFE" number which is trivially known to a third party.  Is someone at "random.org" paying you to encourage people to have them generate their private keys, or did you come by this cluelessness naturally?

I haven't looked recently but last I checked random.org methods were secret and not peer reviewed. So not only may the results be trivially maliciously logged (by the site operators or anyone whos compromised their system; or the operators of the VPSes they use (rackspace cloud)), they're probably more likely to be accidentally flawed because their methods are not reviewed.

A. Attacking an idea or postulate is a great thing.  Attacking a person and calling them "clueless" is ad hominem and is below your status as a moderator of this board.
B. Random.org is peer reviewed here https://www.random.org/media As well as tested by third party orgs like http://www.ecogra.org/  Their methods are not secret but they are not public either.
C. So lets examine your logic:  Since random.org (peer reviewed, certified and in business since 1998) creates a buffer in advance full of billions of ones and zeroes and since it uses https, someone could log the front end usage of these ones and zeros after they leave the buffer and before they hit the https (side note on magnitude: these ones and zeroes from the buffer are used for ALOT of different applications on the site other than coin flips), track the usage by ip, collect and then echo the data once an ip pulls precisely 256 bits of data, run the bits through a key generator, (also try various combinations of the 256bit sequence like only look at the last 256 bits, since the first x bits could have been a test), create a database to collect all of these new bitcoin address and repeatedly query the entire blockchain to see if any of the addresses are extant. If any one address is extant and holds bitcoins, import the corresponding key into a wallet and steal the bitcoins.  OK... I will concede.  This may be possible. Its not likely considering the high level access, the subterfuge necessary, and the high number of bitcoin addresses to generate & query; not probable, but maybe possible.  

So to test your theory I am going to publish a bitcoin address that I created using random.org, leave some BTC there and see if they evaporate.  If they magically walk away, then we will know that someone at random.org is malicious.  If nothing happens, then Im going to stick with my "SAFE" comment.  I will however add a note of caution to the thread warning people that 1) They could get struck by lightning today 2) Earth could get destroyed by a meteor in the next 5 minutes AND 3) Somebody at random.org might guess your intent out of the millions of possible intents by those who use this service, parse through the data looking for precisely 256 bits of interesting target data turn them into a bitcoin key and steal your BTC.

Dear Mythical Hacker at Random.Org:  I created this address with the coin flip service on 02/07/2015.  I flipped 8 coins at once using Polish Zloties.  I pulled precisely 256 bits of data from the buffer to make it easy on you.  Please steal my bitcoins.
Here is the address: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA

A.  He may have been a little harsh, but you need to understand cryptography for some of these things.  And you can't simply claim something is secure.  I am trying to learn about cryptography, and all I've really learned thus far is that there is a lot out there and one can quickly do a lot of damage.
B.  Those are random citations that don't any really appear to be peer review of the methods. For random.org to be tested their methods should be fully disclosed.  They have a question covering this in their FAQ: https://www.random.org/faq/#Q2.2  It talks about gaming and gambling.  Being verified for that is NOT the same as being verified for cryptographic purposes.  Also see https://www.random.org/faq/#Q1.2  Standard security practice before using something in cryptography is that it's open to inspection and that a lot of people have looked at it.  The code they use is not available so how do you know it's right. 
C. In theory the whoever can access the machines they use can get to the random numbers generated.  These include the hosting company, the site owners, hackers with access etc.  gmaxwell did point out that the most likely source of error was a accidentally poor implementation of the random number generator process.  The point is you cannot know because it's all closed source and not reviewed. So do you want to use something that is well reviewed random generator or something that may or may not be random?

A poor random generator may make it possible to solve private keys for 1 in 1000 or 1 in a 1000 000 generated using the site.  The point is even 1 in 1bn is a lot (and I mean a LOT) less secure than other methods used to generate private keys.  So your test address is probably safe, but how safe you won't know, because it's all closed up.  Now if lots of people start using the service (like when someone start recommending them) the odds start looking a lot better for an attacker.

This is my lay understanding of the issues around something like this.

[NewLiberty]

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

LOL.  A "VERY SAFE" number which is trivially known to a third party.  Is someone at "random.org" paying you to encourage people to have them generate their private keys, or did you come by this cluelessness naturally?

I haven't looked recently but last I checked random.org methods were secret and not peer reviewed. So not only may the results be trivially maliciously logged (by the site operators or anyone whos compromised their system; or the operators of the VPSes they use (rackspace cloud)), they're probably more likely to be accidentally flawed because their methods are not reviewed.

A. Attacking an idea or postulate is a great thing.  Attacking a person and calling them "clueless" is ad hominem and is below your status as a moderator of this board.
B. Random.org is peer reviewed here https://www.random.org/media As well as tested by third party orgs like http://www.ecogra.org/  Their methods are not secret but they are not public either.
C. So lets examine your logic:  Since random.org (peer reviewed, certified and in business since 1998) creates a buffer in advance full of billions of ones and zeroes and since it uses https, someone could log the front end usage of these ones and zeros after they leave the buffer and before they hit the https (side note on magnitude: these ones and zeroes from the buffer are used for ALOT of different applications on the site other than coin flips), track the usage by ip, collect and then echo the data once an ip pulls precisely 256 bits of data, run the bits through a key generator, (also try various combinations of the 256bit sequence like only look at the last 256 bits, since the first x bits could have been a test), create a database to collect all of these new bitcoin address and repeatedly query the entire blockchain to see if any of the addresses are extant. If any one address is extant and holds bitcoins, import the corresponding key into a wallet and steal the bitcoins.  OK... I will concede.  This may be possible. Its not likely considering the high level access, the subterfuge necessary, and the high number of bitcoin addresses to generate & query; not probable, but maybe possible.  

So to test your theory I am going to publish a bitcoin address that I created using random.org, leave some BTC there and see if they evaporate.  If they magically walk away, then we will know that someone at random.org is malicious.  If nothing happens, then Im going to stick with my "SAFE" comment.  I will however add a note of caution to the thread warning people that 1) They could get struck by lightning today 2) Earth could get destroyed by a meteor in the next 5 minutes AND 3) Somebody at random.org might guess your intent out of the millions of possible intents by those who use this service, parse through the data looking for precisely 256 bits of interesting target data turn them into a bitcoin key and steal your BTC.

Dear Mythical Hacker at Random.Org:  I created this address with the coin flip service on 02/07/2015.  I flipped 8 coins at once using Polish Zloties.  I pulled precisely 256 bits of data from the buffer to make it easy on you.  Please steal my bitcoins.
Here is the address: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA

A.  He may have been a little harsh, but you need to understand cryptography for some of these things.  And you can't simply claim something is secure.  I am trying to learn about cryptography, and all I've really learned thus far is that there is a lot out there and one can quickly do a lot of damage.
B.  Those are random citations that don't any really appear to be peer review of the methods. For random.org to be tested their methods should be fully disclosed.  They have a question covering this in their FAQ: https://www.random.org/faq/#Q2.2  It talks about gaming and gambling.  Being verified for that is NOT the same as being verified for cryptographic purposes.  Also see https://www.random.org/faq/#Q1.2  Standard security practice before using something in cryptography is that it's open to inspection and that a lot of people have looked at it.  The code they use is not available so how do you know it's right. 
C. In theory the whoever can access the machines they use can get to the random numbers generated.  These include the hosting company, the site owners, hackers with access etc.  gmaxwell did point out that the most likely source of error was a accidentally poor implementation of the random number generator process.  The point is you cannot know because it's all closed source and not reviewed. So do you want to use something that is well reviewed random generator or something that may or may not be random?

A poor random generator may make it possible to solve private keys for 1 in 1000 or 1 in a 1000 000 generated using the site.  The point is even 1 in 1bn is a lot (and I mean a LOT) less secure than other methods used to generate private keys.  So your test address is probably safe, but how safe you won't know, because it's all closed up.  Now if lots of people start using the service (like when someone start recommending them) the odds start looking a lot better for an attacker.

This is my lay understanding of the issues around something like this.

GMaxwell writes from a development point of view.
Make it provably safe therefore trustless (not requiring unusual trust).
I appreciate that view point in a developer, because it makes the code useful for very large values.

The "test" is one which uses very small bait: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA has 0.05 XBT.
It is not a very valid test.  It will not entice someone with an exploit to go after those coins.

[e1ghtSpace]

Since we only generate 256 1's or 0's does that mean that there are only 256^2 possibilities?
Wow, it should be 2^256

[hexafraction]

Since we only generate 256 1's or 0's does that mean that there are only 256^2 possibilities?
Wow, it should be 2^256

No, generating 256 bits means there are 2^256 possibilities. For example, 1 coin flip has 2^1 possibilities, 2 coin flips have 2^2, 3 flips has 2^3, etc. The number of possibilities for n flips is the number of possibilities of n-1 flips times the number of possibilities of that nth flip, hence 2^n.

[fasbit]

I will argue that 256 coin flips from random.org is the best random number possibility available.  And assuming that you push the results through an offline computer using brainwallet offline, you will have a VERY SAFE, VERY RANDOM private key.

LOL.  A "VERY SAFE" number which is trivially known to a third party.  Is someone at "random.org" paying you to encourage people to have them generate their private keys, or did you come by this cluelessness naturally?

I haven't looked recently but last I checked random.org methods were secret and not peer reviewed. So not only may the results be trivially maliciously logged (by the site operators or anyone whos compromised their system; or the operators of the VPSes they use (rackspace cloud)), they're probably more likely to be accidentally flawed because their methods are not reviewed.

A. Attacking an idea or postulate is a great thing.  Attacking a person and calling them "clueless" is ad hominem and is below your status as a moderator of this board.
B. Random.org is peer reviewed here https://www.random.org/media As well as tested by third party orgs like http://www.ecogra.org/  Their methods are not secret but they are not public either.
C. So lets examine your logic:  Since random.org (peer reviewed, certified and in business since 1998) creates a buffer in advance full of billions of ones and zeroes and since it uses https, someone could log the front end usage of these ones and zeros after they leave the buffer and before they hit the https (side note on magnitude: these ones and zeroes from the buffer are used for ALOT of different applications on the site other than coin flips), track the usage by ip, collect and then echo the data once an ip pulls precisely 256 bits of data, run the bits through a key generator, (also try various combinations of the 256bit sequence like only look at the last 256 bits, since the first x bits could have been a test), create a database to collect all of these new bitcoin address and repeatedly query the entire blockchain to see if any of the addresses are extant. If any one address is extant and holds bitcoins, import the corresponding key into a wallet and steal the bitcoins.  OK... I will concede.  This may be possible. Its not likely considering the high level access, the subterfuge necessary, and the high number of bitcoin addresses to generate & query; not probable, but maybe possible.  

So to test your theory I am going to publish a bitcoin address that I created using random.org, leave some BTC there and see if they evaporate.  If they magically walk away, then we will know that someone at random.org is malicious.  If nothing happens, then Im going to stick with my "SAFE" comment.  I will however add a note of caution to the thread warning people that 1) They could get struck by lightning today 2) Earth could get destroyed by a meteor in the next 5 minutes AND 3) Somebody at random.org might guess your intent out of the millions of possible intents by those who use this service, parse through the data looking for precisely 256 bits of interesting target data turn them into a bitcoin key and steal your BTC.

Dear Mythical Hacker at Random.Org:  I created this address with the coin flip service on 02/07/2015.  I flipped 8 coins at once using Polish Zloties.  I pulled precisely 256 bits of data from the buffer to make it easy on you.  Please steal my bitcoins.
Here is the address: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA

A.  He may have been a little harsh, but you need to understand cryptography for some of these things.  And you can't simply claim something is secure.  I am trying to learn about cryptography, and all I've really learned thus far is that there is a lot out there and one can quickly do a lot of damage.
B.  Those are random citations that don't any really appear to be peer review of the methods. For random.org to be tested their methods should be fully disclosed.  They have a question covering this in their FAQ: https://www.random.org/faq/#Q2.2  It talks about gaming and gambling.  Being verified for that is NOT the same as being verified for cryptographic purposes.  Also see https://www.random.org/faq/#Q1.2  Standard security practice before using something in cryptography is that it's open to inspection and that a lot of people have looked at it.  The code they use is not available so how do you know it's right. 
C. In theory the whoever can access the machines they use can get to the random numbers generated.  These include the hosting company, the site owners, hackers with access etc.  gmaxwell did point out that the most likely source of error was a accidentally poor implementation of the random number generator process.  The point is you cannot know because it's all closed source and not reviewed. So do you want to use something that is well reviewed random generator or something that may or may not be random?

A poor random generator may make it possible to solve private keys for 1 in 1000 or 1 in a 1000 000 generated using the site.  The point is even 1 in 1bn is a lot (and I mean a LOT) less secure than other methods used to generate private keys.  So your test address is probably safe, but how safe you won't know, because it's all closed up.  Now if lots of people start using the service (like when someone start recommending them) the odds start looking a lot better for an attacker.

This is my lay understanding of the issues around something like this.

GMaxwell writes from a development point of view.
Make it provably safe therefore trustless (not requiring unusual trust).
I appreciate that view point in a developer, because it makes the code useful for very large values.

The "test" is one which uses very small bait: 1DcS5pEgjnLGJ43h7znVxdcxMfx6pfaZvA has 0.05 XBT.
It is not a very valid test.  It will not entice someone with an exploit to go after those coins.

1. I agree that my measly .05 BTC of bait is not a real enticement.  But it would demonstrate if someone had maliciously swiped the code and was using the site to swipe private keys no matter the balance.
2. I appreciate gmaxwell's point and I added warnings based on his point.  This thread is however, about creating the private key with a coin flip not a web site.  Using a site like random.org is ancillary to the thread and I marked it "educational only."
3. The only thing I claim is safe is: 1) its done offline, 2) its done randomly, and 3) no one can know the method of creation.  I will stick by that maxim. < this is the essence of the thread

[jl2012]

EXTRA SPEED:  .....

Punch your keyboard and take SHA256 of the results. It's way much better than using an online third party RNG.

[NewLiberty]

1. I agree that my measly .05 BTC of bait is not a real enticement.  But it would demonstrate if someone had maliciously swiped the code and was using the site to swipe private keys no matter the balance.
2. I appreciate gmaxwell's point and I added warnings based on his point.  This thread is however, about creating the private key with a coin flip not a web site.  Using a site like random.org is ancillary to the thread and I marked it "educational only."
3. The only thing I claim is safe is: 1) its done offline, 2) its done randomly, and 3) no one can know the method of creation.  I will stick by that maxim. < this is the essence of the thread

Agree with all of this and with the recent revelations:
http://www.cbc.ca/news/technology/nsa-hid-spying-software-in-hard-drive-firmware-report-says-1.2959252
the method is very attractive, still I'd stick with the 64 hex dice rolls over the 256 coin flips.

[teukon]

The only thing I claim is safe is: 1) its done offline, 2) its done randomly, and 3) no one can know the method of creation.  I will stick by that maxim. < this is the essence of the thread

I don't see the need for (3).  Indeed, if (3) is at all useful to your security then I'd claim that you're not introducing enough entropy at step (2) and are being forced to rely on the extra entropy of your method being one among many plausible alternatives.

Certainly, 256 coin flips provides sufficient entropy.  I believe 128 coin-flips is enough for critical cold storage even with the method known but I'm not a cryptographer.

[NewLiberty]

The only thing I claim is safe is: 1) its done offline, 2) its done randomly, and 3) no one can know the method of creation.  I will stick by that maxim. < this is the essence of the thread

I don't see the need for (3).  Indeed, if (3) is at all useful to your security then I'd claim that you're not introducing enough entropy at step (2) and are being forced to rely on the extra entropy of your method being one among many plausible alternatives.

Certainly, 256 coin flips provides sufficient entropy.  I believe 128 coin-flips is enough for critical cold storage even with the method known but I'm not a cryptographer.

While this is true, (3) may be important in case (2) is not perfectly knowable.

If I know all of the circumstances surrounding your coin flips (from even a little bit, up to even the extreme of covert surveillance of your flipping), then (3) would have been helpful to you.  The less others know of your method, the more of your secrets are secret.

Maybe you have your phone with you, and I can turn your phone't mic or camera on via remote.  Maybe I can hear whether you are writing an H or a T or a 1 or 0 by the noise you make while doing it?  The more I know of your process, the worse it is for you.

[fasbit]

EXTRA SPEED:  .....

Punch your keyboard and take SHA256 of the results. It's way much better than using an online third party RNG.

I actually tried this... it worked great!   Thanks!

[NewLiberty]

EXTRA SPEED:  .....

Punch your keyboard and take SHA256 of the results. It's way much better than using an online third party RNG.

I actually tried this... it worked great!   Thanks!

This is a decent RNG for small numbers, but not a lot of entropy for a whole key.  It has only as much as the variety of punches, so it is not so great for high value long term storage if the generation method is known.

[PonZ]

OK... assuming the following:
1. You flip a coin 256 times
2. You convert the results to a private key using all offline resources
3. No one knows how you created your key

Is there any other method more secure than the method proposed by the OP?

[itod]

OK... assuming the following:
1. You flip a coin 256 times
2. You convert the results to a private key using all offline resources
3. No one knows how you created your key

Is there any other method more secure than the method proposed by the OP?

Certainly there is, and being more secure it's also much, much more simple. Just let the Bitcoin-QT client create private keys for you. You have to do zero work, and you are using state-of-the-art. peer reviewed cryptography, based on the reliable RNG.

It's amazing how total amateurs believe they've thought of something bunch of professionals haven't figured out. Now that I've said that, I think that method you've described is certainly better than brainwallets and other half-baked schemes some people use to generate keys. Problem is it has possible flaws if not worked out perfectly, and even if you work it out perfectly it's just not worth the effort since the result can not be superior to what you get from reference Bitcoin client.

[coinableS]

Certainly there is, and being more secure it's also much, much more simple. Just let the Bitcoin-QT client create private keys for you. You have to do zero work, and you are using state-of-the-art. peer reviewed cryptography, based on the reliable RNG.

I think there's a certain novelty type of satisfaction from being able to create your key with a pair of dice or other physical randomness. Bitcoin is so intangible there's something cool about being able to make a part of it your own. Then you get to converting your random string to a public address and the EDSCA curve part and it's all back to the digital world

[PonZ]

OK... assuming the following:
1. You flip a coin 256 times
2. You convert the results to a private key using all offline resources
3. No one knows how you created your key

Is there any other method more secure than the method proposed by the OP?

Certainly there is, and being more secure it's also much, much more simple. Just let the Bitcoin-QT client create private keys for you. You have to do zero work, and you are using state-of-the-art. peer reviewed cryptography, based on the reliable RNG.

It's amazing how total amateurs believe they've thought of something bunch of professionals haven't figured out. Now that I've said that, I think that method you've described is certainly better than brainwallets and other half-baked schemes some people use to generate keys. Problem is it has possible flaws if not worked out perfectly, and even if you work it out perfectly it's just not worth the effort since the result can not be superior to what you get from reference Bitcoin client.

The problem I see with your logic is that you "trust" your computer to create a random number, which is something that computers can't really do with perfection.  As the OP pointed out, we have seen more than one example of users trusting their computer RNG and losing their ass because of it.  At least with a coin (even though its a pain in the ass), the entropy is at the maximum and is provable.  On the other hand, allowing your wallet to create an address is of course easy, but the entropy level is less than a coin flip and possibly even flawed.

[itod]

OK... assuming the following:
1. You flip a coin 256 times
2. You convert the results to a private key using all offline resources
3. No one knows how you created your key

Is there any other method more secure than the method proposed by the OP?

Certainly there is, and being more secure it's also much, much more simple. Just let the Bitcoin-QT client create private keys for you. You have to do zero work, and you are using state-of-the-art. peer reviewed cryptography, based on the reliable RNG.

It's amazing how total amateurs believe they've thought of something bunch of professionals haven't figured out. Now that I've said that, I think that method you've described is certainly better than brainwallets and other half-baked schemes some people use to generate keys. Problem is it has possible flaws if not worked out perfectly, and even if you work it out perfectly it's just not worth the effort since the result can not be superior to what you get from reference Bitcoin client.

The problem I see with your logic is that you "trust" your computer to create a random number, which is something that computers can't really do with perfection.  As the OP pointed out, we have seen more than one example of users trusting their computer RNG and losing their ass because of it.  At least with a coin (even though its a pain in the ass), the entropy is at the maximum and is provable.  On the other hand, allowing your wallet to create an address is of course easy, but the entropy level is less than a coin flip and possibly even flawed.

You haven't been reading carefully. There was never, ever, lost of coins because of Bitcoin-QT (bitcoind) RNG. You should not trust Android wallet or browser Javascript page to do generate you keys, but you can safely assume that reference implementation does it perfectly. There are comprehensive bias tests for Bitcoin-QT RNG results, and it always performed flawlessly in every one of them.

[DeathAndTaxes]

You haven't been reading carefully. There was never, ever, lost of coins because of Bitcoin-QT (bitcoind) RNG. You should not trust Android wallet or browser Javascript page to do generate you keys, but you can safely assume that reference implementation does it perfectly. There are comprehensive bias tests for Bitcoin-QT RNG results, and it always performed flawlessly in every one of them.

You misunderstand the scope of the issue.   All the repeat r value attacks were not due to flaws in the wallets themselves but the fact that the entropy for the CSRNG comes from the operating system,  In the case of the android platform there was a flaw which resulted in repeat values under some circumstances.  A valid wallet using flawed data from the OS is just as weak as a flawed wallet.  Even saying "bitcoin core RNG" is misleading.  There is no Bitcoin core RNG.  Bitcoin core requests random bytes from OpenSSL.  OpenSSL gets that from rand_lib.c and where rand_lib.c gets it from depends on a lot of variable like the build environment and the target operating system but ultimately it is provided by the OS.    It would be impossible for OpenSSL to have a flaw  flaw that went undiscovered for years.  Right?

In modern day crypto the RNG is the weak point and it is for the most part an opaque black box.  If I was the NSA I would be putting the bulk of my crypto breaking budget into weakening the RNG.  Strong Algorithm + Weak Numbers = Breakable Crypto.   Hardware RNGs are not a magic bullet either.  Here is a 'random' sequence of bytes.

Code:

13660f36ade6a8084c9a8f25a4e8d8a2bb3c2cb7f6f92ad225514d682ace46a6eb37f4ebf16999c15c43e0de53499a62b69259e8ea2dbf129a59452cf046e63b
b123588e2d26698190eb260e6fddf8d65a13120793fc03c2dc0b07b210f8c32ffe94091da210c8d7e439e32a0d2e1a6089fd4ee4a01bc71b64387036c232eaa8
e247b808959dd0db4ab6392e50cdbacd940e632af0f651815d981e079e03f922bb1bde6c0385f7cf76c26ff6f6688bf63427ae301a12d9bb75322f0e01e331b2
4e2ab2f5f2b18693405a7b111a81935786e0da4baad72c0ef30dea5eaf7026ec4ca15d295a959acfb2431960289bd0a02c35d8a5a5819f6fb3b36d9984f91b28
43399ba67ab67bf116391690c797c36838114f04a005b0d160130c2ba124213bf37033d0c8206b1aab24be34e13562579275bff41e2b4129da1bffcb4b953802

Was this generated random from a secret entropy source such that it couldn't be reproduced.  If your processor's RNG produced that sequence would you trust it? The sequence is too short but even a much longer sequence (billions of bytes) would pass standard statistical tests for bias.  The bad news is it is trivially reproduced but without insider knowledge almost impossible to prove it isn't 'random'.  Want to know how I generated it?

Code:

next_64_not_so_random_bytes = HMAC-SHA512(count, key)
where key = "The NSA is happy to provide you weak numbers" and counter=1 for the initial request and increments on each additional request.

The NSA got caught putting malware into hard drive firmware.  To pull that off required detailed insider knowledge and access to manufacturing private key to sign the false firmware.  Do you think it is beyond possibility that they may attempt to introduce weaknesses into the hardware RNGs in one or more processors.  How are you going to verify there isn't a weakness in silicon (at 20nm no less) of every processor you own and will ever own?  Is your OS right now using the RDRAND instruction to fill its entropy pool?  Did you even know that was a possibility?  Starting to see why I said RNGs are black boxes.   Validating it requires validating not just the application but the library, the OS, and possibly even the hardware platform itself.

Now generating all your keys individually by physical random event is probably overkill however the nice thing is that two technologies make that unnecessary.  The first is RFC6979 which generates signatures without using a random k value and the second is HD wallet algorithms which can generate a lifetime of keypairs from a single high entropy seed.

So the question becomes can you PROVE your random numbers are strong (high entropy)?  I can produce high entropy numbers from a dice, coins, or cards trivially and be guaranteed they can't be reproduced.  Can you say the same about the black box random numbers provided by your OS?

[shawshankinmate37927]

The NSA got caught putting malware into hard drive firmware which involved insider knowledge and access to manufacture keys.  Do you think it is beyond possibility that they may attempt to introduce weaknesses into the hardware RNGs in one or more newer processors.  How are you going to verify there isn't a weakness in silicon (at 20nm no less) of every processor you own and will ever own.

It's hard to believe there are still people out there that trust their PC's to generate keypairs after the latest revelations.  https://firstlook.org/theintercept/2015/02/17/nsa-kaspersky-equation-group-malware/

[itod]

You haven't been reading carefully. There was never, ever, lost of coins because of Bitcoin-QT (bitcoind) RNG. You should not trust Android wallet or browser Javascript page to do generate you keys, but you can safely assume that reference implementation does it perfectly. There are comprehensive bias tests for Bitcoin-QT RNG results, and it always performed flawlessly in every one of them.

You misunderstand the scope of the issue.   All the repeat r value attacks were not due to flaws in the wallets themselves but the fact that the entropy for the CSRNG comes from the operating system,  In the case of the android platform there was a flaw which resulted in repeat values under some circumstances.  A valid wallet using flawed data from the OS is just as weak as a flawed wallet.  Even saying "bitcoin core RNG" is misleading.  There is no Bitcoin core RNG.  Bitcoin core requests random bytes from OpenSSL.  OpenSSL gets that from rand_lib.c and where rand_lib.c gets it from depends on a lot of variable like the build environment and the target operating system but ultimately it is provided by the OS.    It would be impossible for OpenSSL to have a flaw  flaw that went undiscovered for years.  Right?

In modern day crypto the RNG is the weak point and it is for the most part an opaque black box.  If I was the NSA I would be putting the bulk of my crypto breaking budget into weakening the RNG.  Strong Algorithm + Weak Numbers = Breakable Crypto.   Hardware RNGs are not a magic bullet either.  Here is a 'random' sequence of bytes.

Code:

13660f36ade6a8084c9a8f25a4e8d8a2bb3c2cb7f6f92ad225514d682ace46a6eb37f4ebf16999c15c43e0de53499a62b69259e8ea2dbf129a59452cf046e63b
b123588e2d26698190eb260e6fddf8d65a13120793fc03c2dc0b07b210f8c32ffe94091da210c8d7e439e32a0d2e1a6089fd4ee4a01bc71b64387036c232eaa8
e247b808959dd0db4ab6392e50cdbacd940e632af0f651815d981e079e03f922bb1bde6c0385f7cf76c26ff6f6688bf63427ae301a12d9bb75322f0e01e331b2
4e2ab2f5f2b18693405a7b111a81935786e0da4baad72c0ef30dea5eaf7026ec4ca15d295a959acfb2431960289bd0a02c35d8a5a5819f6fb3b36d9984f91b28
43399ba67ab67bf116391690c797c36838114f04a005b0d160130c2ba124213bf37033d0c8206b1aab24be34e13562579275bff41e2b4129da1bffcb4b953802

Was this generated random from a secret entropy source such that it couldn't be reproduced.  If your processor's RNG produced that sequence would you trust it? The sequence is too short but even a much longer sequence (billions of bytes) would pass standard statistical tests for bias.  The bad news is it is trivially reproduced but without insider knowledge almost impossible to prove it isn't 'random'.  Want to know how I generated it?

Code:

next_64_not_so_random_bytes = HMAC-SHA512(count, key)
where key = "The NSA is happy to provide you weak numbers" and counter=1 for the initial request and increments on each additional request.

The NSA got caught putting malware into hard drive firmware.  To pull that off required detailed insider knowledge and access to manufacturing private key to sign the false firmware.  Do you think it is beyond possibility that they may attempt to introduce weaknesses into the hardware RNGs in one or more processors.  How are you going to verify there isn't a weakness in silicon (at 20nm no less) of every processor you own and will ever own?  Is your OS right now using the RDRAND instruction to fill its entropy pool?  Did you even know that was a possibility?  Starting to see why I said RNGs are black boxes.   Validating it requires validating not just the application but the library, the OS, and possibly even the hardware platform itself.

Now generating all your keys individually by physical random event is probably overkill however the nice thing is that two technologies make that unnecessary.  The first is RFC6979 which generates signatures without using a random k value and the second is HD wallet algorithms which can generate a lifetime of keypairs from a single high entropy seed.

So the question becomes can you PROVE your random numbers are strong (high entropy)?  I can produce high entropy numbers from a dice, coins, or cards trivially and be guaranteed they can't be reproduced.  Can you say the same about the black box random numbers provided by your OS?

The fact that Bitcoin-QT (bitcoind) get's entropy from OS is not a weakness, it's a strength. There a few parts of code more thoroughly examined then the code which produces /dev/urandom on Unix-derivatives, and if you trust Microsoft enough that you use Windows at all then you can trust MS counterpart CryptGenRandom for entropy. On a single user machine it's impossible to exhaust source of entropy for the simple task of generating the keys, and if you generate them for multiple people you should certainly know how not to exhaust it.

Those two OpenSSL bugs that appeared lately have nothing to do with RNG. Nobody can guarantee anything, but that part of the code has been battle-tested. I agree that deterministic keys and deterministic signing are better than the RNG based ones, but /dev/urandom certainly beats the crap out of the guy who flips the coins and then uses offline web pages to convert the result to WIF.

[DeathAndTaxes]

The fact that Bitcoin-QT (bitcoind) get's entropy from OS is not a weakness, it's a strength.

By that logic the affected android wallets getting entropy from the OS was also a strength as well.

There a few parts of code more thoroughly examined then the code which produces /dev/urandom on Unix-derivatives, and if you trust Microsoft enough that you use Windows at all then you can trust MS counterpart CryptGenRandom for entropy.

I guess you are unaware of the 2008 Debian RNG flaw or Windows 2000/XP CryptGenRandom flaw or the Java runtime SecureRandom flaw.  In all those cases the affected code was in production on hundreds of millions of systems sometimes for years before the flaw was discovered.  

but /dev/urandom certainly beats the crap out of the guy who flips the coins

No at best it is as secure.  The problem is that if it is insecure you are probably not going to find out about it until after the fact.

[DeathAndTaxes]

Big, issue, you flip same coin 256 times, so you loose entropy

Care to explain that one?

If I flip heads 20 times in a row using a fair coin what is the odds that it will come up heads on the next flip?

[fasbit]

Big, issue, you flip same coin 256 times, so you loose entropy

Care to explain that one?

If I flip heads 20 times in a row using a fair coin what is the odds that it will come up heads on the next flip?

50% < A true "fair coin" has no idea what you flipped in the past... so its 50%/50% ..period
In fact, I would argue, that as you approached 256 flips, you would get bored and would gradually change your enthusiasm and energy, thereby adding entropy.

[R2D221]

Although flipping a coin is theoretically 50%/50%, in practice it may be different according to the shape of the coin.

https://www.youtube.com/watch?v=AYnJv68T3MM

[fasbit]

Although flipping a coin is theoretically 50%/50%, in practice it may be different according to the shape of the coin.

https://www.youtube.com/watch?v=AYnJv68T3MM

If you took a coin and flipped it 100,000 times and it was heads only 49,000 times instead of the predicted 50,000 times, you could argue that the coin was biased due to some sort of imbalance or what ever your rational was, BUT the bottom line is this:  if you don't publish your results, no one will know the bias, and therefore, no one could sabotage the outcome.  If you were creating addresses for other people this could be a problem.  But for home use... you are rock solid, even with a bias of 49,000 to 51,000.

[itod]

The fact that Bitcoin-QT (bitcoind) get's entropy from OS is not a weakness, it's a strength.

By that logic the affected android wallets getting entropy from the OS was also a strength as well.

There a few parts of code more thoroughly examined then the code which produces /dev/urandom on Unix-derivatives, and if you trust Microsoft enough that you use Windows at all then you can trust MS counterpart CryptGenRandom for entropy.

I guess you are unaware of the 2008 Debian RNG flaw or Windows 2000/XP CryptGenRandom flaw or the Java runtime SecureRandom flaw.  In all those cases the affected code was in production on hundreds of millions of systems sometimes for years before the flaw was discovered.  

Both bugs, Android and Debian 2008 were exactly the same bugs, OpenSSL PRNG not being seeded from the OS's /dev/urandom. There's no chance that same bug will ever be introduced in Bitcoin-QT since it's one of the most watched parts of the code. I don't know what exactly Windows 2000/XP CryptGenRandom bug was, but then again that's what everyone who chooses to use non-opensource code gets.

but /dev/urandom certainly beats the crap out of the guy who flips the coins

No at best it is as secure.  The problem is that if it is insecure you are probably not going to find out about it until after the fact.

On this one we agree, deterministic is better than random. Bitcoin reference implementation should switch to it as default as soon as developers are ready to write the new part of the code.

[fasbit]

Someone posted a video on Youtube of this process and cited this article:

https://youtu.be/ieHoQ4sGuEY

[Martins17]

Thankx for the cool guide

[youyou_]

thx dude ^^

[bob123]

Never thought of such a funny idea 

[MrFreeDragon]

I found this topic from the youtube video of the guy who flipped the coin 256 times  in 2015 year, and he made a link to this subject.

I developed a project (bitcoin Visual private key generator) for making this process faster.

The decsussions of the project are here: https://bitcointalk.org/index.php?topic=5187401

The project site is here: https://btckeygen.com