Proof of agreement
This article covers a simple method using freely available tools for people to create an agreement amongst themselves which is digitally signed by all participants. The agreement is created in such as way that the identity of all participants, the authenticity of their signatures, and the time the agreement was signed is proven and can be verified by anyone. These verifications are very strong, but don't rely on any third-party authority and can be carried out by anyone using freely available tools without any specialised skills or knowledge. A cover letter is provided that is to be included with the agreement and contains the signatures and an explanation of what is being proved, how the proof works and how to verify it for oneself.
Contents
Public key cryptography
Public key cryptography is the kind of system where the owner holds a secret private key that gives them ownership over the resource the key is protecting, and an associated public key which is safe to share publicly. Two popular example are PGP keys and Bitcoin addresses.
With PGP key pairs, anyone can use a public key to encrypt information knowing that only the person holding the private half of that key will be able to decrypt it. Also, the holder of the private key can sign messages resulting in a digital signature than anyone can verify using the public key. When someone sends a message they can sign it with their PGP key so that the recipient can use the sender's public key to ensure that the message was really sent by the holder of the private key.
In the case of Bitcoin, anyone can send money to any public bitcoin address, knowing that only the holder of the associated private key will be able to spend that money. As with PHP, the holder of the private key is also able to sign messages with it, and anyone can verify that the signature is valid using the public key.
Publicly associating yourself with a key
The first part to being able to create verifiable agreements between people, is being able to verify an irrefutable connection between a physical person and a public key they hold.
If you haven't already done so, you can publish any of your public keys either on your own site, or on a site that supports various forms of keys in user's profile information such as Keybase, OneName or some of the social networks such as Mastodon. For the purpose of creating a good agreement, it's a good idea to use a recognisable profile picture and include other details such as web site and email addresses in your profile.
This information may be solid at the time the agreement was made, but we want to make an agreement that can stand the test of time. The profile page you've chosen to use for the agreement may not be very permanent, for example the domain could expire, the company running the site go bankrupt or you may decide to delete your account and move to another platform.
A very useful tool to help us with this problem is the "Wayback Machine" at web.archive.org. This site has snapshots of billions of web pages at specific times to preserve the history of the web. And if by chance your profile does not exist in the Wayback Machine when you search for it, you will be given the option of adding it right then.
Here is a concrete example. I have a profile in a platform called KeyBase - or at least I did have at the time I wrote this! There were a few snapshots of my profile page already in the Wayback Machine when I checked just now, which you can see in the picture to the right, or by going there yourself.
This is a frozen snapshot of time, no matter what happens with Keybase in the future or what happens to my specific Keybase account, this snapshot will continue to exist in the Internet Archive which is supported by many organisations. You can see that this profile relates a number of things together; it has my name (full name would be better for this purpose) and photo, some of my web addresses and two public keys (highlighted). For most people there would also be provable connections with Facebook and Twitter etc, but I have deleted all such accounts out of my life!
You can also check the other related addresses for recent snapshots in the Wayback Machine, in this case we have organicdesign.pub/@aran (my Mastodon) which shows links back to my Keybase account and my blog, and my main site organicdesign.nz which shows links to the Mastodon and my Gitlab account. Using this tool also allows people to check how far back through time these various forms of identification go back.
So what we have here is a very strong connection between myself and a lot of known public activity and information about me, and this is all publicly and timelessly connected together along with three public keys that I control, a PGP key, a Bitcoin address and a ZCash address. Any of these keys could be used for the rest of the process which involves creating and signing the text of the agreement and using a blockchain to freeze a copy of these signatures in time. I'll show how it can be done with the Bitcoin address as is the simplest and best supported method.
Creating the agreement text
The agreement itself is something that only the participants can figure out, once they've arrived together at a definite statement that they all believe clearly describes what they're all in agreement on that's the first step in creating the text. For my example there will just be me as the only participant and a tiny fragment of text, but of course in reality there could be a number of participants and the text will be a whole document in the form of a PDF or something.
Aran agrees to buy a pizza for his wife if Bitcoin does not reach a new all time high in 2019.Here we see that the agreement text includes the names of all the participant(s) that will be signing, but we need to now include their profile URL that is known to exist in archive.org. You don't need to specify the archive.org URL in the agreement text, but it's important to know that a recent snapshot of it exists at the time the agreement is created.
Another important addition is to include the time, and the current Bitcoin block along with its hash - by including the block's hash, we're providing irrefutable proof that the agreement was not made before this block as created, because the block hash cannot possibly have been known in advance.
Our updated agreement has now been edited so that the identities of the participants includes their profile URL, and the time and block information is appended to the end.
Aran (keybase.io/aran) agrees to buy a pizza for his wife if Bitcoin does not reach a new all time high in 2019.
This agreement was created at 00:10, 2019-08-04 UTC, the Bitcoin block number was 588492 with a hash of
0000000000000000000da391191dd04feefc62299cdfd89ca77c662836da422fHere I've used only my first name and associated myself only with my chosen online profile, but in a real agreement you would use your full name and a physical address and maybe the number of a government ID like a passport as well.
Getting the hash (fingerprint) of the agreement
The next step is to get the hash of the agreement, which is a unique fingerprint that matches the exact agreement text. Remember that from this point on the agreement text cannot be changed, even if you see a typo or problem, otherwise the entire rest of the process will need to be repeated again. We'll use SHA-256 hashes because those are currently the most popular throughout the crypto world. You can do this using an online tool such as this one where you can simply drop the file on the page to get the hash as shown in the image to the right, or if you're using Linux or Mac you can do it on the command line as follows (you'll need to know the path and filename of your agreement document).
sha256sum /path/to/document.pdfIn my case the SHA-256 hash of my agreement is:
49d51d6d6c93bf02b0ec8eade41414333f45d864bc2f91f3319e54ada09632b2Signing the agreement
Only the holder of the private half of a key-pair can sign anything with their private key, and it's not something they might inadvertently do like accidentally clicking "I agree" or opening a file with a virus in it. A digital signature is a long sequence of letters and numbers that looks just like a hash, but if someone knows that it a signature and they also have the message it is signing and the public key that the message was signed with, then they can easily prove for themselves whether or not the signature really was signed by the key holder and corresponds to that exact message. In general it's easier to sign the message's hash rather than the message itself, especially if it's large. This avoids common mistakes like accidentally adding or removing spacing or newlines from the beginning or end of the document text which would lead to a completely different signature.
Digitally signing is not a difficult process, but it cannot be done with online tools because that would be a serious security risk since it needs to be done using your private key which should never be shared. In the popular electrum wallet signing a message is done from the tools menu, which opens the simple window shown on the right where you simple enter you message (or it's hash in our case) and the address you want to use the associated private key from. You then click "sign" and the digital signature code will be created for you. Note that you can also use this same window for verifying signatures. the signature for our message is as follows (note that I'm using a different address than the one shown in my for this example, but in reality it's very important that you use the same address).
HFodpjwKOps5B51ClBlh6/xsdu50nHSz1JBZnP0L1v2NU5vm+075sO9OlSkQ+9YFrspF3Hxs0kEMEQkZF3SvhgY=Each of the participants need to create their own signatures since it requires access to the private key, but each of the participants should also verify all the other participant's signatures too, to make sure they're all ok before moving on to the final stages of the process.
To verify a signature we can either use our own wallet software that we used to create the signature, or one of the commonly available online tools such as this one which is shown in the image below. Note that there is no security concern in the case of verifying a signature because one only needs the public key and the message (and of course the signature) to do this.
Recording the signing in the blockchain
In the first step, we added the current Bitcoin block number and it's hash to the message as a means of irrefutable proof that the agreement the participants have all signed was not created before that block came into existence. But in this step we'll be including into our agreement irrefutable proof that the was not signed after the current block. This block might be a block or two ahead of the last one we used, but it still provably places the entire process into a very small window of about an hour. This is an important step, because people change their bitcoin addresses frequently and so we need to be able to verify that the signature was made at the time the participant was an active owner of the address.
What we'll do first is create a hash of all the signatures joined together. We need to be careful that the order of the signatures in this sequence is the same as the order of names in the agreement so that it is easy for anyone to recreate this sequence in order to verify the hash later if they wish.
The easiest way to do this is to create a text document containing all the signatures pasted in one per line with no empty lines or spaces or any other content at all apart from one of the signatures on each line. Then get the hash of this file the same way you did in the step above where you got the hash of the agreement document.
In my case my SHA-256 hash of my single signature is:
3ad8b2ffc472e5dd829cda0f7af35a114ba5f6f883c43e904f1eb16d6ae8f0d5What we'll do now is use on of the many available blockchain "notary" services to prove our hash existed at this time by inserting it into the blockchain. The service we'll use is proofofexistence.com. Now although I said we're using completely free tools, there is actually a small fee for this service because putting anything in the Bitcoin blockchain requires a transaction fee to the network.
This tool works in the same way as the other one where you drop a file onto the page and it gets the hash, but in our case we already have our hash, so we need to click the "input a hash" link first and paste out hash into the supplied input box. Then you'll see a page similar to the image on the right which you can see contains my example hash. You simply send the transaction fee amount they request to the specified address, and when they receive it you'll be given the transaction ID of your proof.
In my case the ID they gave me was 0ff3015b63ee2ca94ccc88c814539e14cb27c9340c9c07542a3ae3fb5029beb7. Now if you view that transaction in any Bitcoin block explorer you'll be able to see your hash right there in the output scripts section of the page as shown below.
This hash of my signature will always be there throughout history now encoded into block 588632. This shows irrefutable that at 21:44 on August the 4th 2019 my signature for this exact agreement existed. And due to the agreement that has been signed containing the hash of the current block at the time we started the agreement singing process, the text we have signed irrefutably cannot have existed before 00:10 on the same day (at block number 588492). That's a pretty large window of time in my case, but that's because writing this explanation has taken a lot longer than the process itself would usually take!
Documenting the agreement
There's just one final step in this process. We need to create a cover page that accompanies the agreement which actually includes the signatures. The agreement document itself can't be edited and have the signatures added, because then the hash of the document would no longer match, and the signatures would be invalid.
The cover page also explains what is being proved and how it works, so that anyone who reads the agreement is able to go through the process of verification themselves. Here I've created a cover letter that you could adapt for your own use by replacing the specific information such as times and hashes and rewording to suit the kind of people you expect to be reading your agreement.
Explanation of independent digital proof of agreement
This cover letter describes the use of public freely available digital tools to facilitate the agreement of the participants specified in this associated document with the document's contents. These tools and the process described here provide a proof, as well as an explanation of the proof and how to verify it, of the following three things:
- 1. Association of each participant with their online public identities and with a cryptographic public key
This is achieved by including a public profile URL along with the other identifying information for each participant in the agreement text. Each participant has ensured that their profile URL has a snapshot in the Internet Archive (web.archive.org) close to the time of the agreement that will always be accessible. This profile links the participant to their various other online profiles and activities, and more importantly to a bitcoin address they own which was used to digitally sign the agreement.
- 2. Digitally signatures to show all participants are in agreement with this associated document
Each participant has digitally signed the SHA-256 hash (unique digital fingerprint) of the agreement document which is 49d51d6d6c93bf02b0ec8eade41414333f45d864bc2f91f3319e54ada09632b2 using the private key of the bitcoin presented in their specified profile URL. Only the holder of the private key associated with the address digitally sign messages for that address, they are considered the owner of that address because they can spend the balance held within that address.
Aran's digital signature which he created by signing the has of the document with the private key for the bitcoin address 12ppeoYVy4Un1BZq7isE29ZwZHsTR7uciX is HFodpjwKOps5B51ClBlh6/xsdu50nHSz1JBZnP0L1v2NU5vm+075sO9OlSkQ+9YFrspF3Hxs0kEMEQkZF3SvhgY=
Anyone can validate the authenticity of the above signature using the option in their own Bitcoin wallet, or using one of the many available online tools such as tools.qz.sg. Simply enter the Bitcoin address that was used for signing, the document hash shown above, and the signature and click "verify". In addition, anyone can also confirm that the hash does indeed match the document by using the sha256sum command on their own computer, or by using one of the many available online tools such as emn178.github.io/online-tools.
- 3. That the signing of the agreement took place within a specific short window of time
This is an important step because it's important to know that the signature took place at a certain time, as it's possible the participants are claiming that the agreement took place in the past when in reality they may have only just created it. Or the Bitcoin addresses in question may no longer be under the control of the participants.
First by including the number and hash of the Bitcoin block that was current at the time of writing the agreement, we have ensured that the agreement must have been created after 00:10 on August the 4th, 2019 because there's no way to have known that the hash of block 588492 was 0000000000000000000da391191dd04feefc62299cdfd89ca77c662836da422f before that block came into existence. You can verify the block number, hash and times all match for yourself by entering that block number in one of the many available Bitcoin blockchain explorers such as blockchain.com.
Secondly, the hash of all the signatures combined together (in this case just my own signature) is 3ad8b2ffc472e5dd829cda0f7af35a114ba5f6f883c43e904f1eb16d6ae8f0d5. By including this hash in the data of the Bitcoin transaction having the ID of 0ff3015b63ee2ca94ccc88c814539e14cb27c9340c9c07542a3ae3fb5029beb7 which is included in block 588632 of the Bitcoin blockchain, we have ensured that the document must have been signed before 21:44 on August the 4th, 2019. You can verify that this hash exists in that transaction yourself by entering that ID in one of the many available Bitcoin blockchain explorers such as blockchain.com and seeing it in the "output scripts".
For more detailed information about this process please see organicdesign.nz/proof_of_agreement.
