dcrtime: Blockchain-based Timestamps

BY MARCO PEEREBOOM ON JUNE 14, 2017

Per the 2017 Decred Roadmap, one of the major deliverables is a proposal system that allows users to participate in the governance of Decred. The proposal system will have 2 main components: a blockchain-based timestamping service and a public version-controlled repository for proposal data. The subject of this entry is dcrtime, the timestamping component. Dcrtime was written by Marco Peereboom over the past couple months and is the result of collaboration between Marco, Jake Yocom-Piatt and Dave Collins. The primary motivation for dcrtime is the desire for the proposal system to have maximum transparency and accountability, while having a minimal onchain footprint. In terms of its onchain footprint and overall design, dcrtime draws on the work of Peter Todd’s opentimestamps, which allows a nearly unlimited number of hashes to be timestamped onchain with the inclusion of a single merkle root in a transaction. The process used by dcrtime can be summarized as follows:

• allow users to submit 32-byte hashes, which are accumulated, organized into a merkle tree and hashed down to a merkle root
• create an episodic onchain transaction that includes that merkle root
• allow users to verify their data is timestamped by responding to queries by hash with the corresponding merkle root, transaction hash and a merkle path for that hash once the transaction is mined

Although dcrtime has been designed as a component of the proposal system, it is expected to have generic utility as a public timestamping service. Any third party that is interested in using dcrtime to generate externally verifiable timestamps can do so free of charge by using our public mainnet server. We expect this to be particularly useful in scenarios where transparency, accountability and time-ordering are of key importance, in either a public or a private context, e.g. computer security, data integrity and various compliance contexts. A more detailed discussion of dcrtime can be found below.

dcrtime architecture

The dcrtime service is comprised of four components:

The proxy is a simple daemon that proxies dcrtime API calls to the non-public dcrtime server. The proxy and server are in fact the same daemon but run in either proxy or server mode. The reason these two daemons are separated is to prevent a daemon sitting on the internet with a wallet passphrase in memory and also in order to be able to scale the frontend. It accepts a JSON REST API call and ensures it can be decoded and immediately transmits it to the backend daemon that does the work. The reply from the dcrtime server is also relayed back to the caller. The magic really happens in the dcrtime server, and for the remainder of this entry, we will not make further mention of the proxy.

Now that it is clear how dcrtime works in conjunction with dcrd and dcrwallet, it is useful to understand how it fits into the larger proposal system. The proposal system’s second component, a version-controlled repository, will episodically drop timestamped “anchors”. As data is added to the proposal repository, each commit has a corresponding hash, and commit hashes will episodically be timestamped using dcrtime. Anchored hashes will have their corresponding merkle path and transaction hash stored in the proposal repository once the transaction containing the merkle root is mined. By storing the anchor data in the proposal repository, the proposal system can have all of its commits and anchors verified against a copy of the Decred blockchain.

dcrtime example

The server collects digests that are sent to it and every hour these digests are reduced to a single merkle root. This merkle root is then anchored in the decred chain in a transaction. An example of such a transaction on testnet can be seen here. The merkle root can be found in the entry that is an OP_RETURN followed by a digest. In our example it is:

OP_RETURN 9788d5d7b85f2b68ec21d26e738dce6cdd367ee0ec58b53ad6bd4d46b0bc3018

We included the client reference application which conveniently is called dcrtime. Uploading a digest to the server can be done as follows:

$ dcrtime --testnet -v myfile.txt
8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6 Upload myfile.txt
8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6 OK     myfile.txt
Collection timestamp: 1497009600

If we immediately ask the server for it the server will return information and indicate that it has not been anchored yet. For example:

$ dcrtime --testnet -v
cd90cc268d9ceef6e276bfa7a615c5f85b5a27b0d917ee3f1f1e5d5598f2fa00
cd90cc268d9ceef6e276bfa7a615c5f85b5a27b0d917ee3f1f1e5d5598f2fa00 Verify
cd90cc268d9ceef6e276bfa7a615c5f85b5a27b0d917ee3f1f1e5d5598f2fa00 Not anchored

Once the digest has been anchored we can retrieve it and find out the transaction the merkle root was anchored in. Note that the client does verify the merkle path that the server returns.

$ dcrtime --testnet -v 8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6
8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6 Verify
8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6 OK
  Chain Timestamp: 1497013614
  Merkle Root    : 8496855341883fdc90cc532f8304d1c46a60586fb15d99f07e41bb5ab19c79c6
  TxID           : 4172a560a7035c169c4da60cba2cb1fbac686bd01224e09a1a56ce5e6f31cff0

Conclusion

dcrtime represents the first of two components of Decred’s proposal system. Interested third parties can make use of the free public timestamping service provided via dcrtime, which runs hourly, on the hour, as of this post. If you are interested in using dcrtime for timestamping, please contact us on Slack for assistance. If you would like to comment on this article, join us on the Decred Forum.