OpenTimestamps


This webpage is an interface to create and/or verify timestamp proofs using the OpenTimestamps protocol and its free public Bitcoin calendar servers. [If in a hurry, skip this introduction and go straight away to timestamping.]

A timestamp demonstrates that a document existed in a specific status prior to a given point in time, providing that document with a certain sure date (e.g., postmark). Law requires dates to be certified by public officials and notary services; for digital documents, timestamping is usually based on the digital signature of a Certification Authority (CA).

Anyway, digital data can be securely timestamped using the attestation of its hash value in a blockchain transaction. The hash value 'uniquely' identifies the document (as if it were its unique digital fingerprint), the transaction extends its native blockchain timestamping to the included hash value, therefore proving its existence at a given point in time. As a result, the blockchain attestation of the hash value proves also the existence of the original document itself prior to the timestamp moment.

Timestamping and content of a blockchain transaction are secured by the amount of computational effort performed after the transaction inclusion in a block of the chain. Indeed, the more blocks are added to the chain after a given block, the more computationally intensive is tampering with the data of that block; even just trying to alter the timestamp of a transaction becomes technically and economically prohibitive, especially in the Bitcoin blockchain case.

Although there are many ways to realize a timestamp, OpenTimestamps is a vendor-independent blockchain-agnostic open protocol that defines a set of operations for creating provable blockchain timestamps and later independently verifying them; as such, it allows for third party auditability and is suitable for regulatory prescriptions.

OpenTimestamps attestation proofs can be verified independently from any server, vendor, or centralized infrastructure, simply using a local copy of the blockchain (e.g., a Bitcoin full node). Trust minimization is achieved because of this distributed, decentralized, independent, uncensorable, and cross-jurisdictional design. This webpage interface is just a facility and, since a webpage cannot access the local filesystem, relies for verification on public Bitcoin block-explorers (e.g., blockstream.info) instead of a local copy of the blockchain.

To avoid the inefficiency of one blockchain transaction for every timestamp, an OpenTimestamps server provides aggregation of multiple document hashes in a Merkle tree data structure and attests only the hash of the Merkle tree root. The inclusion of a hash value leaf in a Merkel tree can be cryptographically proved and such a proof is part of the attestation; as a result, the single attestation of the tree root implicitly attests all the leaves. This aggregation before attestation approach results in almost unlimited scalability.

While anyone could timestamp with any permissionless blockchain by paying the appropriate transaction fees (using the OpenTimestamps protocol or any alternative approach), for convenience there are multiple public OpenTimestamps calendar servers (e.g., btc.ots.dgi.io), free to use without any registration or API key. A single calendar server can offer its services to multiple remote OpenTimestamps clients: verifiable timestamp are created with no cost for the clients. The public free OpenTimestamps calendar servers use Bitcoin as timestamp notary, i.e., they make a Bitcoin transactions to attest the root hash value in the Bitcoin blockchain.

Timestamp and Verify


Use the box below to:

  1. Submit a file for timestamping
    When a file is dropped in the box:
    1. its hash value is calculated locally inside the browser without disclosing the document to third parties, not even the OpenTimestamps servers, preserving privacy;
    2. the hash is then submitted to multiple redundant public OpenTimestamps servers to obtain an attestation proof of its existence (timestamp);
    3. a submission receipt is downloaded (as .ots filetype); this is not the attestation proof yet: it is incomplete and cannot be verified immediately, as it can take up to one hour (or even more in some circumstances) for the transaction to be included in the blockchain.
    In time, the hash value will be attested in a block: then, the servers it has been submitted to will be able to upgrade the submission receipt to attestation proof. As long as at least one server is properly functioning, the timestamp is ensured.
  2. Upgrade a submission receipt to attestation proof
    If the file dropped in the box is a submission receipt (filetype *.ots):
    1. an upgrade to proof attestation is downloaded from the calendar servers if available;
    2. the proof, if any, is verified using public Bitcoin block-explorers.
  3. Verify an attestation proof
    If the file dropped in the box is an attestation proof (filetype *.ots):
    1. an updated proof is downloaded from the calendar servers if available;
    2. the most recent proof available is verified using public Bitcoin block-explorers.

Drop here a file to timestamp it or a receipt/proof (*.ots) to verify it.




Warnings


Attestation proofs can be verified independently from any OpenTimestamps server or facility. The same is not true for the submission receipt, which can only be upgraded to proof using the OpenTimestamps calendar(s) used for submission.

The user is responsible to store both the timestamped document (which has never been shared with the OpenTimestamps servers) and its attestation proof (which technically might be stored by the OpenTimestamps servers).

While the OpenTimestamps protocol is blockchain agnostic, a timestamp is as reliable as the used blockchain:

  • very reliable when using Bitcoin because that blockchain is secured by huge computational power (proof-of-work);
  • much less reliable with other public permissionless blockchains;
  • when used with a private permissioned blockchain its reliability depends on the trustworthiness of the chain governance: in this case a traditional certification authority is probably better.

It should be obvious, but it is worth mentioning that timestamping (using the OpenTimestamps protocol or any alternative approach):

  • can be selectively revealed to show convenient evidence and hiding inconvenient evidence (e.g., timestamping a bet on a given outcome and its opposite, later revealing only the realized one);
  • does not prove authorship (that should be proved using a digital signature);
  • can be repudiated if not digitally signed;
  • does not ensure veracity, validity, correctness, or accuracy of the timestamped document.