Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS"

but people will do it anyway, the level of insanity out there is really high https://www.reddit.com/r/btc/comments/68pusp/gavin_andresen_... or even https://arstechnica.com/security/2015/05/crypto-flaws-in-blo...

also why would it be a good idea to use a centralized source of "entropy"....? why is NIST involved at all?



> also why would it be a good idea to use a centralized source of "entropy"....? why is NIST involved at all?

Actually there's a very good use-case for NIST's Random Beacon in [OpenTimestamps](https://opentimestamps.org/): preventing miners from backdating their blocks undetectably.

Background: The Bitcoin protocol constrains block timestamps to not be >2hrs in the future, by virtue of the (kinda weak) rule that nodes reject forward dated blocks. However, for a timestamp proof that rule is irrelevant: a forward-dated block is a weaker proof, not a stronger proof. Unfortunately the reverse is problematic: a Bitcoin block is valid so long as its timestamp is > the median time of the last 11 blocks; nodes will happily accept backdated blocks, with the only constraint on backdating being that you eventually push the difficulty up.

Now, if you assume it's only a small percentage of miners doing this, the median time past rule helps you a bit, but it's hard to model; if a majority of miners are backdating blocks, there's a risk of backdated timestamps being generated with significant (hours/days) of backdating. While that risk is mostly theoretical because it's easily detected, it'd still be nice to rule it out.

Since the NIST Random Beacon represents a nonce that NIST claims did not exist in the past, we can easily use it to constrain and detect block timestamp backdating, a useful improvement to the security of OpenTimestamps. While not a priority, I'll probably add support for random beacons to OpenTimestamps at some point, and have the calendars do this automatically as part of the timestamping process.

Of course, I wouldn't do this with just NIST: all blockchains act as random beacons, so it'd make sense to use a merkle tree of this NIST random beacon and a few other blockchains at the same time to achieve this.

And finally, yes, you're quite right: using the random beacon as a source of entropy is beyond stupid.

edit: Come to think of it, the simplest possible implementation of this would be a cronjob that just grabbed the latest beacon and timestamped it... All you need to achieve is proof that the block had a dependency on the beacon after all.

edit2: ...and it's live: https://alice.btc.calendar.opentimestamps.org/experimental/i...


In re: why is NIST?

Did you read the explanation on the page? This seems to fall clearly within NIST's mandate.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: