Investigate and possibly improve accuracy of timestamp oracle

[AshwinSekar]

Problem

The timestamp oracle uses timestamps created at vote tx generation, which are then fed into a stake weighted median to estimate the cluster frozen timestamp for a given block. This might not be accurate during volatile situations when consensus lags from replay as well as periods of large vote refreshes.

Proposed Solution

Investigate:

1. Who uses the timestamp oracle and what are the expected bounds for accuracy?
   Initial proposal says "external auditors or law enforcement".
2. What exactly are we trying to measure?
   Initial proposal says block produced, however "processed" / "frozen" were also mentioned. Code indicates "voted".
3. Is the oracle expected to be within the bounds of accuracy for unrooted forks?

Depending on the answers to 1) and 2), it might be more accurate to move the timestamp to the frozen bank time in replay.

If 3) indicates we should be accurate for minor forks as well, then it might be necessary to move the timestamp oracle out of the vote program entirely, as minor forks might only get a few votes, allowing a small amount of stake to skew timestamps on longer minor forks.

[mvines]

1. Who uses the timestamp oracle and what are the expected bounds for accuracy?
   Initial proposal says "external auditors or law enforcement".

A resolution of ~24 hours was sufficient for the original consumer of the feature: stake account unlocks. The first external entity that put requirements on this feature too also was ok with a ~24 hour resolution.