The whole approach is based on document hashes, in our case using an algorithm called SHA-256 (the same used in the Bitcoin protocol). Hashing, is 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.
The hashes we’re using look something like this:
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 achieve this by using a Merkle tree structure. In essence certificates’ hashes are combined and then re-hashed to create a tree like structure which represents the whole set of certificates and any change to any of the certificates will result in a completely different root (top) hash.
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). We remember the transaction identifier for later use.
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. The metadata contains, at least, the merkle root hash, the merkle proof, the transaction identifier, the issuing institution and the public address used.