Why OpenTimestamps does not "linearize" its transactions



Summary:

In an email exchange, Jeremy Rubin proposed a model for timestamping services, which he claims is necessary for any correct timestamping service to follow. The concern arose when the timestamp services were asked to do things that they were not claiming to do. Specifically, timestamp proofs only prove that a message existed prior to some time t. The OpenTimestamps proof consists of commitment operations that act on an initial message m, leading to a message known to have been created at some point in time, usually a Bitcoin block header. The commitment operation requires the property that for a given input message m, the output H(m) can't be predicted without knowledge of m. Timestamp proofs are used as a one-sided bound on when a given message existed, proving a message existed prior to some point in time. Linearization is not a solution to this issue since we care more about proving statements about messages than timestamp proofs themselves. Random beacons offer dual-sided bounds on when messages were created and can be solved by creating messages known to have been created after a point in time and unpredictable prior. Bitcoin block hashes make for a perfectly good random beacon for use-cases with day to hour level precision, while for higher precision absolute time, there are many trusted alternatives like the NIST random beacon, Roughtime, etc.


Updated on: 2023-05-22T20:34:39.255302+00:00