OpenTimestamps (OTS) is an open-source project that aims to provide a standard format for blockchain timestamping. With the advent of systems like Bitcoin, it is possible to create and verify proofs of existence of documents (timestamps) without relying on a trusted third party; this represents an enhancement in term of security, since it excludes the possibility of a malicious (or careless) notary to compromise the timestamp.
OTS defines a set of rules for conveniently creating timestamps and later independently verifying them. Currently, timestamping with Bitcoin is fully supported, however the format is flexible enough to support a variety of methods.[a]
Anyone could create timestamp with the permissionless blockchain by paying the transaction fees, for convenience OTS built an infrastructure that aggregates timestamp requests from users and packs them into transactions fund by public calendar servers; as a result, users can timestamp for free, in a trust-minimized setting.[b]
What is a timestamp
A timestamp is a proof that some data d existed prior to a certain point in time.
To create such proof, it turns out that it is not necessary to publish d on the blockchain, which would be expensive, but it is enough to commit d to the blockchain. Such commitment proves that d existed prior to a certain block, in the sense that if d changes, then the proof becomes invalid and hence useless.
The proof consists in a sequence of commitment operations, such as
These operations are the cryptographic path that proves that d commits to a certain block header. In other words, that d caused the block header to have its value, indeed, if d were different then, due to the mathematical properties of commitment operations, the block header would be different.
To verify the commitment, the operations are applied in sequence to the data d, then the result, which should be the transaction merkle root, is checked to be equal to the one observed in the blockchain; if the check goes fine, then one can assert that d existed prior to the block.
For the timestamped file
hello.txt, the OTS proof is encoded in a file named
hello.txt.ots which contains:
- the hash of the timestamped file;
- the commitment operations;
- one or more attestations on the blockchain.[d]
With this information, a challenger can independently verify that
hello.txt existed prior to a certain block.
OTS provides users multiple and easy ways to create and independently verify timestamps:
- With opentimestamps-client in Python;
- With java-opentimestamps;
- On opentimestamps
In the following sections it is shown an example of the usage of the Python client.
The stamp operation creates the first version of the timestamp. It is applied to the file for which you want to prove its existence (original file).
$ cat hello.txt Hello World! $ ots stamp hello.txt Submitting to remote calendar https://a.pool.opentimestamps.org Submitting to remote calendar https://b.pool.opentimestamps.org Submitting to remote calendar https://a.pool.eternitywall.com
The stamp operation calculates the SHA256 hash of the original file, concatenates a random 128-bit nonce to maintain privacy, and recalculates the SHA256 hash, sending this unique value to the calendar servers. Each of the calendar servers will add the received hash to its Merkle tree and return the necessary response to generate the initial OTS file. This OTS file is still incomplete because it does not yet contain the record in the blockchain.
Once a reasonable time has elapsed, the user will run the upgrade operation on the same OTS file. This will communicate with the calendar servers and update the OTS file with the Bitcoin block header attestation.
$ ots upgrade hello.txt.ots Success! Timestamp complete
It is also possible to create timestamps for several different files simultaneously. In that case, the stamp operation will send a single request to the calendar servers with a Merkle root derived from the original files, and later, that same operation will calculate the Merkle tree paths and create the timestamps for each one of the original files.
The verification of the OTS proof requires both the OTS file and the original file. The user must also have an up-to-date Bitcoin node[f] on their own machine to perform the verification without relying on trusted third parties.
$ ots verify hello.txt.ots Assuming target filename is 'hello.txt' Success! Bitcoin attests data existed as of Mon Apr 16 01:15:16 2018 CEST
Show timestamp information
The basic structure of a timestamp is divided into three main sections:
- File hash
- Merkle tree construction
- Bitcoin block header attestation
The timestamp is saved in a binary file to save space and avoid problems of interpretation, encoding and compatibility between systems. Generally, this file has a .ots extension and its magic number is
The info operation presents the content of the timestamp on a human-readable format. In this case, a single attestation of the hello.txt file is shown, which hashes all the way to the Bitcoin block header at block 518387.
$ ots info hello.txt.ots File sha256 hash: 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340 Timestamp: append 72d8a09f54b12580b48c2f7c7dea4ce0 sha256 -> append fe0d089c9bfe5289c3ee579904af3551 sha256 prepend 5ad3d92b append 8fefb42191040403 verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org') sha256 prepend f0e8b62a519b0b8fad763c33c558e0179a43b8d89cb4130b6dbaa91e3d3252f6 sha256 prepend beca183da3f86784a7d54778bc48e78c570245d51474f32475e6d1851989b140 sha256 append a95879c35c15ace7dc5fd1d2cf0a7d9b0e4110b5b8a74da4c64082835f6f6a2e sha256 append cf9b259e4506235f97225706f3a675f51ecf2657814639d87e4e6f42d8581ae7 sha256 prepend e3b7ff694e1b14b4420556ca77ea8e9509e44b7fbed0dc9a3b67c00fcf016ca2 sha256 prepend 01000000017230dffb1edd7cae0c8feb3fec7c91c34b33b22fdfac071b83e790ce34254b340000000017160014a4282cbf0f17fd6d51b61da f7cf4d56e32183b60fdffffff02d7c062000000000017a914365c46ff772b9f1da73efeb2c559777e1a2c33b4870000000000000000226a20 append f2e80700 # Bitcoin transaction id 7e6e5aafa1fc9d933992621a7ac321dc7b9368d0e1baa72ff77665b07b75315f sha256 sha256 append d67f1615f986694d707d7d044883c7885f3dded2ac9df5f6b9270a5bdda38aa3 sha256 sha256 append e551a80b2bdd88f417fc95014662f7a65d8c0c4d833b6df034bc12f1af35b953 sha256 sha256 append 0902830fc37fde4996c350de40c0ae621c739ce002a7be4b3725d7e281fc02a3 sha256 sha256 append 7ac1e262423598f1477825882f78ededc98b44bf0136f059e438391aa0e7a686 sha256 sha256 prepend 9ee83975bef756160275a336203059109fd4336572e5e47e9a3edadb82a8934c sha256 sha256 append 7a3229b63fc7a88d4edde4aa5b855416265842120fde246462271e5418f895bd sha256 sha256 prepend a4c712ca130f63862f329874f11466eb74ee7b505c191344ee11b30d14ca4946 sha256 sha256 append 13bf98cdb708ed3321b8d48ff290c5bdbefa6fb9be34717e97a3f3cfa9b87994 sha256 sha256 prepend d2aec8bd2edf2d6d10606df92f1b8b53a97362d7aba7d3fa15bf55c0aab94e35 sha256 sha256 verify BitcoinBlockHeaderAttestation(518387) # Bitcoin block merkle root b4f71191dc633cfb125543211022b1059d78b42a359408da5958fc15231ef6de
- A snapshot of the complete 750,000,000 Internet Archive files were timestamped so that it is not possible to modify them without being noticed. This action was performed by committing the Merkle root of all those files on a single Bitcoin transaction.
- Bitcoin Core uses OpenTimestamps to timestamp merge commits.
- As of now, it is possible to timestamp also with Litecoin and Ethereum, although verification is not supported.
- The worst thing that a calendar can do is not to timestamp the users data; if that happens, then users can timestamp by themselves.
- Note how, by conveniently combining these commitment operations, it is possible to traverse a Merkle tree. Similarly to Bitcoin, OTS makes use of this commitment structure to pack several timestamps in one transaction.
- A timestamps is in form of a tree: from the starting hash, multiple branches leads to different attestations. This provides the redundancy that protect users in case a calendar is down.
- The website is the easiest method to create and verify timestamps but it is the less secure: differently from the previous ones, users cannot verify independently the timestamp, since the verification is made by a third party.
- It is not strictly required a full node, indeed the attestation are on the block header, thus a pruned node is enough to verify a timestamp. Note that a SPV node has the whole block header chain, so, in theory, it could verify timestamps, however it does not verify blocks and thus has a much lower security compared to pruned nodes.
- "OpenTimestamps client, latest version". Retrieved 13 April 2018.
- "OpenTimestamps code repository". Retrieved 7 June 2018.
- "OpenTimestamps website". Retrieved 7 June 2018.
- Gao, Yuefei; Applications, Hajime (2017). "A Decentralized Trusted Timestamping Based on Blockchains". IEEJ Journal of Industry Applications. 6 (4): 252–257. doi:10.1541/ieejjia.6.252.
- Todd, Peter (September 15, 2016). "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin". Retrieved May 5, 2018.
- Weilbach, William Thomas (December 11, 2017). "Practical Application of Distributed Ledger Technology in Support of Digital Evidence Integrity Verification Processes". Archived from the original (PDF) on 17 Apr 2018. Retrieved May 5, 2018.
- "OpenTimestamps client repository". GitHub. Retrieved June 7, 2018.
- "Header magic definition in python-opentimestamps". GitHub. Retrieved 7 June 2018.
- Wirdum, Aaron van (June 6, 2017). "OpenTimestamps Has Timestamped the Entire Internet Archive — Here's How". Bitcoin Magazine. Retrieved May 5, 2018.
- "Bitcoin Core devtools README - Create and verify timestamps of merge commits". GitHub. Retrieved May 5, 2018.
- Douglas Heaven (February 4, 2019). Nature (ed.). "Bitcoin for the biological literature". Retrieved February 22, 2019.
- Todd, Peter (September 16, 2016). "Solving the PGP Revocation Problem with OpenTimestamps for Git Commits". Retrieved May 5, 2018.