Published on: 2022-06-19T11:04:50+00:00
In a recent email exchange on the bitcoin-dev mailing list, concerns were raised regarding the use of OpenTimestamps (OTS) for timestamping. One user expressed worry about the requirement to publicize .ots files and suggested including more cryptographic information in the original OP_RETURN to eliminate the need for this. However, it was clarified that publication is not actually a part of the OTS system.The discussion also touched upon the issue of security with .ots files when shared with other parties. Without cryptographic pinning, there is a possibility that a fourth party could replace the .ots file, changing the timestamp to a later date and compromising the validity of the data. Additionally, there were concerns about the potential loss of transaction history containing OTS hashes in chain forks.Another user highlighted the limitations of OTS in proving the timing and uniqueness of documents. While OTS can prove the duration of a document, it cannot demonstrate its shortness or whether an earlier version was already published. The user referred to this as the system being "designed to be broken" as it allows individuals to rewrite history by republishing others' documents under different contexts.The conversation also delved into the scalability and efficiency of OTS. It was noted that through the use of merkle trees, OTS can timestamp tens of thousands of messages with a single transaction, making it a more efficient option. However, there were suggestions for additional measures to ensure the security and uniqueness of timestamps, such as publicizing nonces and document hashes with user consent.Overall, the discussions highlighted the complexities and considerations involved in using timestamp services like OpenTimestamps. While they provide valuable information about the existence of content at a given time, there are limitations and security concerns that need to be addressed to ensure the validity and reliability of the timestamps.In the context of proving the existence of a message prior to a certain point in time, linearization is not considered as a viable solution. The focus is on verifying statements about messages rather than timestamp proofs. To address this issue, random beacons provide a solution by offering dual-sided bounds on the creation time of messages. By creating messages that are known to have been created after a specific point in time and with an unpredictable prior, the accuracy of timestamp proofs can be ensured.For use-cases that require day to hour level precision, Bitcoin block hashes serve as an effective random beacon. However, for higher precision absolute time, there are several trusted alternatives available. These include the NIST random beacon and Roughtime, among others.Overall, random beacons offer a way to establish the creation time of messages, allowing for the verification of statements without relying solely on timestamp proofs. Whether using Bitcoin block hashes or other trusted alternatives, random beacons provide a valuable tool for various precision requirements.
Updated on: 2023-08-02T06:52:21.283384+00:00