Topic: How to Create a Bitcoin Receive Address from a Coin Flip (Read 14723 times)

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://bitcointalksearch.org/topic/bitcoin-visual-private-key-generator-5187401

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

Never thought of such a funny idea 

thx dude ^^

Thankx for the cool guide

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

https://youtu.be/ieHoQ4sGuEY

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.



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.

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.

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

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.

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?

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


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.  

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.

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.

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/

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.


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?


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?

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.

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.

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

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.

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?

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.