Self-Verifiable Certificates on the Bitcoin Blockchain

//Self-Verifiable Certificates on the Bitcoin Blockchain
Self-Verifiable Certificates on the Bitcoin Blockchain 2018-05-10T16:59:17+00:00


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.

The University of Nicosia has been issuing academic certificates whose authenticity can be verified through the Bitcoin blockchain from 2014. 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.

More details on the process used up to Mar 2017 with an explanation of how to verify the certificates issued can be found here.

In May 2017 we have upgraded our methodology for issuing and verifying certificates and details on how this is accomplished 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.

2. Root Hash

There are hundred of students per graduation and each will be awarded a certificate. However, we want to be able to issue only one hash that represents all those certificates.

We need 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.

We achieve this by using a Merkle tree structure. In essence certificates’ hashes are combined and then re-hashed to create a tree like structure with the following characteristics:
(a) The root hash can represent the whole set of certificates and any change to any of the certificates will result in a completely different root hash.
(b) A merkle proof can be created that proves that a certain certificate is part of a merkle root hash.

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 We remember the transaction identifier for later use.

4. Self-verification

If the certificates are to be self-verifying, each certificate needs 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 placing extra metadata in the pdf file after the issuing in the blockchain. The metadata are stored in a way that will not change the file structure so it is possible to verify as we will see later. The metadata contains the merkle root hash, the merkle proof, the transactoin identifier, the issuing institution and the public address used.

The University of Nicosia publishes the public address used to issue the certificates which private key is controlled by the University and can be used to prove the authenticity. Furthermore, the time and date of the issuing is also publicized at which point we can say definitively that the only hash during that time frame from that specific address represent the University of Nicosia certificates.

The public address used to issue certificates will be publicized on our Twitter channels, website and Facebook page so that everybody can confirm that the address belongs to the University.

Verifying the Certificate

To verify a certificate, one just has to either:

1. Confirm the authenticity using an online validator

Use our validator to upload the certificate and verify it!

The code for validating the certificate is open source and anyone may offer a third-party validation service.

2. Confirm the authenticity yourself

Alternative one can use the open source code to validate locally.

a. Install a compliant library, e.g.:
b. Follow the instructions on how to run the library to validate the certificate

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.