How to Create a Bitcoin Receive Address from a Coin Flip

[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 ^^