One of the great promises of blockchain technology is that it can serve as a decentralized permanent unalterable store of all types of information or assets, not just as a currency or payment system.

Today, we are happy to share with you that the University of Nicosia has issued the first academic certificates whose authenticity can be verified through the Bitcoin blockchain. These certificates are being issued to students who successfully completed or participated in DFIN-511 Introduction to Digital Currency, which is the first university course offered on the topic of cryptocurrency.

The index document for the first session of DFIN 511 (Summer 2014) can be found here.

Details on how these certificates have been issued and how one can authenticate them can be found below.

Design Parameters

We would like to share with you some of the mechanics of how the process worked and some of the challenges we came across. When we first thought about how this could be done, we set for ourselves the following design parameters:

• The process would involve no other services or products other than the Bitcoin blockchain
• The process would allow someone to authenticate a University of Nicosia certificate without having to contact the University of Nicosia
• The process would allow someone to complete the process even if the University of Nicosia no longer existed (or, more likely, if the University of Nicosia website no longer existed in its current form or records are lost and so on)

Note that for this process to work, we not only have to (a) ensure that authentic certificates can be verified but also (b) that there is no way for someone to copy the whole process and create a set of inauthentic certificates before our first public announcement. Our transaction will always predate any potentially fraudulent submissions to the blockchain.

In some ways, university related documents are an excellent and very tough test case for this type of situation. The average business document might have a validity of a few months or years. Whereas it is normal and expected for someone to be able to check the validity of a university diploma, decades or centuries after it is issued. So we can’t rely on, say, this website being available in 60 years.

Design Decisions

1. Hashes

The whole approach is based on document hashes, in our case using an algorithm called SHA-256 (the same used in the Bitcoin protocol). For those who are not familiar with hashes, they are an algorithm that takes as input any arbitrary data (in our cases, it would be the PDF documents of the certificates) and produce a series of unique numbers and letters. You cannot recreate a document from a hash, but you can recreate the hash from a document. So, if I let you know that the SHA-256 hash for a certain authentic certificate PDF is:


you can’t reverse engineer the hash to know whose certificate it is, but if you have a copy of the certificate, you can apply the SHA-256 hash algorithm to reproduce this number. As we will see, hashes are critical to our overall approach.

A sample certificate can be found here.

2. Index

Our initial thought was that we would enter the hash of each certificate into the blockchain but we then reconsidered that decision and decided instead to make an index document containing all the hashes of all the certificates and then, subsequently, hash the index document and enter that hash into the blockchain.

We did this for two reasons:
(a) It is wasteful to enter each certificate individually in the blockchain in that it adds more data to the blockchain than is needed to accomplish our objective
(b) It is less secure to enter each individually. If we enter one hash only into the blockchain, then we can announce to the world that this is the one and only hash for this program’s summer session 2014 certificates. If we enter hundreds or thousands of hashes, we have to publicly acknowledge each of them which is much clumsier and prone to error.

The technically inclined will note that a more advanced way to handle this would be to build a Merkle tree. We felt the simplification of simply having an index document was worth it in terms of increased accessibility in people’s ability to self-verify.

3. Blockchain Record

The hash of the document is then entered into the OP_RETURN field in an unspendable Bitcoin transaction to serve as the permanent record underpinning the overall approach we are taking (something previously demonstrated by www.proofofexistence.com).

4. Timing and Instructions

If the certificates are to be self-verifying, the certificate plus the index need to include all the instructions needed to self-verify. This presents an interesting chicken-and-egg problem in that we don’t know which Bitcoin transaction the hash will be included in until we create the transaction, but if we enter the transaction into the certificate we will change its hash.

We resolved this issue by noting in the documents a time range when we planned to enter the transaction on the documents, entered the transaction into the blockchain during that time period and were very careful to make no public statements until that period was complete.

At which point we can say definitively that the only hash during that time frame that could represent the University of Nicosia certificates is ours.

5. Public Access

The index document is on our website (in fact on this page), but if it only appeared here, then our process is no better than putting a list of hashes on our website and does not require the blockchain at all.

For this process to be decentralized, we need people to be able to find any copy of the index and be able to self-verify, not to have to rely on our website being up and running. We are distributing the index far and wide, including to our students and we are publicly acknowledging the hash through our Twitter channels, website, Facebook page and any other mechanism we can think of.

That way, even if the University of Nicosia and its website disappear, so long as the validated hash still exists as a public record, people can identify the correct copy of the index and, from that, authenticate any certificate.

Verifying the Certificate

To verify a certificate, one just has to run our process in reverse as follows (and these instructions can be found on the index document):

1. Confirm the authenticity of the index document

a. Ensure that you are using a valid index document supplied by the University of Nicosia
b. The index document PDF can be found at http://dcurrency.wpengine.com/certificates and at other online locations distributed by the University of Nicosia or in the student files
c. The validity of the index document can be confirmed by reviewing the OP_RETURN codes in blockchain transactions confirmed between 1200 and 1400 GMT on September 15th 2014.
The SHA-256 hash of the valid index document, prepended by “UNicDC ” (554e6963444320 in hex encoding) will be found in one transaction during that period
In fact, the actual transaction is this one: cb4f0cf471ac262096162484f51abcf1a0a6a2c9db21a4e2f5abbe41860d3ca0 and the correct hash for the authentic index is: 71f8291827ae0806619cddbbd648d4b82ffb2115f5f0d0224e13ad3e7b06a32d

2. Confirm the authenticity of the certificate

a. Produce a SHA-256 hash of the PDF certificate to be authenticated
b. Search for the certificate’s SHA-256 hash within the authenticated index document. If the hash code is found, then the certificate is authentic

Index Documents by Course Cohort


Final Thoughts

We would welcome feedback on this process. It strikes us as there is room for improvement in terms of having ways to publicly validate the hash, but otherwise, the process is a reasonable one. Finally, we thank our students, instructors and teaching assistants who participated in this course, covering a new topic area in academia and a new method of validating their participation.