> We have no reason to believe this is happening, and it’s hard to imagine that the institution in charge of running the nation’s most accurate clocks would als

> We have no reason to believe this is happening, and it’s hard to imagine that the institution in charge of running the nation’s most accurate clocks would also be putting fake timestamps on the Beacon data. This is hopelessly naive. We don't need to imagine that the NIST has been compromised: this has already happened. The NIST collaborated with the NSA to put a backdoor in the Dual_EC_DRBG standard[1]. Given this, I think we have to view the NIST as a compromised, untrusted entity. As such, we must assume that an attacker has both the seed values and the NIST's private key. Given an attacker with this power, none of the approaches mentioned in the article provide security: > SHA-512 is not known to be broken at present, and so even working backwards through one of the SHA-512 stages is essentially impossible; two rounds is impossible squared. The proposed attacker knows all the inputs to the SHA-512 hash and therefore does not need to reverse the hash. > So if you’d like to make your adversary’s work super-duper difficult, combine the Output Values from today at 7:00 pm and yesterday at 7:00 pm. Your adversary will have to work backwards through 2 x 24 x 60 = 2,880 SHA-512 stages to make the chain verify, still assuming that he knows the NIST’s secret key. The proposed attacker knows all the inputs to the two SHA-512 hashes and therefore does not need to reverse the hash. > But suppose SHA-512 were broken and working it backwards were easy instead of being ridiculously difficult. Nothing prevents you from writing your contract to take the Output Value, add one to it, and run this value through a better hash of your choosing. Now the bad actor inside the NIST has to reverse your chosen hash function as well. The proposed attacker knows all the inputs to whatever hash function you choose, and therefore does not need to reverse the hash. Adding one does effectively nothing, and I'm not sure how to prove what it doesn't do, because I'm not sure what the author thinks adding one does. A better try might be to use an adequately-sized random secret key with a unique, incrementing nonce to generate the random numbers via a pseudo-random function. However, you shouldn't trust that this works without seeing a mathematical proof--something sorely lacking in the original article. And even if it does work, it's counter-productive to use the NIST random numbers as input for your function. There are plenty of other sources of inadequate randomness, and at least if you're using your own inadequately-random numbers you can determine how inadequate the input randomness is and act accordingly. In short, the first step toward the perfect coin flip is to stop trusting the NIST. [1] http://en.wikipedia.org/wiki/Dual_EC_DRBG http://en.wikipedia.org/wiki/Dual_EC_DRBG