Bitcoin & Blockchain Programming #006 – Blockchain Notary System Design

by Albert Szmigielski

Notary System
Let’s design a notary system. A system that can notarize a document and store it. There are three solutions possible: a decentralized one, that can keep functioning for ever, a centralized system that would depend on a company running it, and a combination of both. We would like the system to be decentralized, so that in the event of our company’s demise the system can keep on functioning. This is a desirable property to have as wills may need to exist for decades before they are executed. In addition to this we will have a centralized component where we keep the information stored for our users. Added functionality like storing authorized users able to access a will can also be implemented in the future. If death notification becomes automated in the future we can incorporate it into our system to automatically send the most current will to all parties concerned. We can utilize Ethereum (or any other system that may emerge) in a future iteration of our system, to make even the storage of the information decentralized.

In order to support a decentralized approach the system would be based on a current Bitcoin wallet with added functionality. This approach lends itself easily to a desktop version and a mobile version, that are both decentralized. The user would have all they need.

The user’s identity would be a Bitcoin address. The creation and security of Bitcoin addresses has already been proven, there is no need to reinvent the wheel. The system would pick only one address for the purpose of notarizing a document. This is so that any future modification of the will can be attributed to the same user. Using Bitcoin addresses ensures the required characteristics of confidentiality, integrity, availability, and non-repudiation. Using the Bitcoin blockchain allows us to take advantage of the most secure blockchain today. If another blockchain emerges that is safer than Bitcoin’s we would be able to move the document hashes to that chain (of course this would require a system addition).

The app would require a strong password so only the authorized user can create and modify a will.

Creation of will
The user can create a will in their favorite editor. Once the will is finished our system takes a hash of it, and signs it with the user’s private key.

Authenticity of a document

The signature of the document is embedded in a Bitcoin transaction and therefore it is stored on the blockchain. (The transaction is signed as well.)

Revenue (optional)
The transaction would be structured so that a fee for the service is directed to our address. Of course a transaction fee to the network would also be included.

GUI (optional)
The system could have a browser based front end for the desktop (with bitcoind running in the background). For mobile we can build a mobile app (based on an existing mobile wallet) with a GUI or mobile users can use our web version.

Scalability (optional)
If our service becomes extremely popular, we can collect the document hashes and create a Merkle tree. We submit only the Merkle tree root to the Bitcoin network, but each client would receive the Merkle tree path to their signature. This requires a centralized component to collect signatures and build a Merkle tree. This approach begs for a web version.

A web version could also be created which would be a semi-centralized solution. We could host user wallets (undesirable) or simply require payment from users for each transaction (keeping track of identity is required).


The system can also be implemented on top of existing mobile wallets. Therefore extending our decentralized system to mobile would be straight forward. The web version can of course also be used on a mobile device. A CSS would format the website accordingly.


returns a Bitcoin address with account name “notary”. The address is created if the account does not exist.

take_hash (hash_type , filename):
returns a hash of file contents, we will use an existing hash function of course

sign (hash):
signs the hash with user’s private key corresponding to the identity created

submits the signature to the Bitcoin blockchain using OP_RETURN
returns a transaction ID and a reference for fast look up

verify (tx id, ref, file):
returns true if the blockchain stored signature matches the file contents signature


Proof of Concept

Written in PHP for ease of coding/testing/web deployment
require_once 'jsonRPCClient.php';
require 'OP_RETURN.php';

1. Generates end-user identity.
A call to bitcoin-cli getaccountaddress
$ID = ($bitcoin-> getaccountaddress("notary"));

2. Calculates a hash for a provided file.
$HASH = hash_file ('sha256', $FILE);

3. Signs the hash using the above identity.
A call to bitcoin-cli signmessage
$DIGEST= hash( 'sha1', $HASH);
$SIG = ($bitcoin-> signmessage($ID, $DIGEST));

4. Submits a transaction to Blockchain including the signature in the OP_RETURN field.
We use the OP_RETURN library here:
we first take a digest of the hash and then sign it so the data fits in the OP_RETURN field

5. Verifies the authenticity of the submitted file using the above transaction Id.
We retrieve the signature and verify it with a call to bitcoin-cli verifymessage against a submitted file.

$VER_FILE = "will.txt";
$VER_HASH = hash_file ('sha256', $VER_FILE);
$VER_DIGEST= hash( 'sha1', $VER_HASH);

$VER_SIG = ($bitcoin-> verifymessage($ID, $SIG_BLOCKCHAIN, $VER_DIGEST));

Screen shot of running code:


Leave a Reply

Your email address will not be published. Required fields are marked *