[ots-dev] On random beacons and backdated blocks
pete at petertodd.org
Fri Jul 21 04:45:57 AEST 2017
Thought it might be useful to CC the mailing list on this comment I just wrote
on a HN thread about NIST's Random Beacon service:
> 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
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
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 455 bytes
Desc: Digital signature
More information about the ots-dev