[ots-dev] On random beacons and backdated blocks

[Peter Todd]

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:

https://news.ycombinator.com/item?id=14815208

> 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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <https://lists.opentimestamps.org/pipermail/ots-dev/attachments/20170720/8f7f16ba/attachment.sig>