Thursday 19th January 2017
Signing the hash of a file into the Bitcoin blockchain has been well-known practise for a while now, and cryptographically proves the existence of a particular file at a particular time. The record is permanent, and can be checked at a later date. Once your hash is in the blockchain, it is impossible to change/remove it.
There are two main ways of doing this. The first method involves broadcasting a deliberately erroneous transaction to the network (known as "provably unspendable"). A provably unspendable transaction has space for a small amount of data to be included in the broadcast, which in this case is used to store the hash of the file. Documentation on this process can be found on the Bitcoin wiki. Using this method, you will only be required to send the transaction with a high enough fee for it to be confirmed. No Bitcoin output is required.
The alternate method involves generating a Bitcoin address based on the SHA-256 hash of the file and sending Bitcoin to said address. With this method, you will never know the private key that is associated with the address. This is because a ECDSA key is never generated and hashed, instead you use the hash of the file that you want to sign into the blockchain. Take a look at the technical process of generating Bitcoin addresses on the Bitcoin wiki. Contrary to the first method, this does require a Bitcoin output. At the current time this isn't very significant, since you could send just 1 Satoshi (0.00000001 BTC), which is worth £0.0000073148 as of 19/Jan/2017.
Many transactions created this way and used for the purpose of signing file hashes can be seen on the "Strange Transactions" page at blockchain.info.
Bitcoin transaction fees are currently around £0.07 for a transaction of this sort. To summarise, this is how much it will "cost" to sign the hash of your file onto the blockchain.
The problem with this system is that it does not prove when the final version of the file was actually created. I could sign a decade old file into the blockchain and it would only prove that the file was created BEFORE that time. While this type of proof may be useful in some situations, a two-way solution is better.
The only real way to achieve this is by including some information in the file itself that proves that it was created AFTER a particular time. The first thing that you may think of is to include a current news article, since this information could not have been produced before the reported event actually happened. While this is a good solution that most people will understand, it is better to use a cryptographic proof. By including the most recent Bitcoin blockchain block hash in your file, you can cryptographically prove that the file was created AFTER the current time. For example:
Information on recent Bitcoin blocks can be found easily on sites such as blockchain.info:
Now we have the full solution: by including the hash of the most recent Bitcoin block in the file, and then signing the hash of the file onto the blockchain, you can prove that the final version of the file was created between two timestamps. These being the timestamp of the most recent block hash at the time, and the timestamp of the Bitcoin transaction.
In order to test the proofs, we can imagine different circumstances:
Signing the hash of a file onto the Bitcoin blockchain can be done manually as outlined above, however there are online services available designed to automate the process:
Proof of Existence (proofofexistence.com) is possibly the most well known service. You simply select a file, it is hashed and an address is presented to which you must pay 0.005 BTC (worth £3.67 as of 19/Jan/2017).
OriginStamp (originstamp.org) is much more versatile than Proof of Existence. There are more options as to what you can submit to the site, instead of just uploading a file, and it's also a completely free service!
I was surprised to see at first that it is a free service, however it works in quite in interesting way. Instead of having a separate Bitcoin transaction for each verified file, all of the hashes for every file submitted to the site each day are aggregated into one master file which is then used as the seed for generating a Bitcoin keypair. This means that there is only one Bitcoin transaction per day that verifies all of the files that were submitted that day. The downside of this is that you may have to wait up to 24 hours from submitting your file for the actual Bitcoin transaction to take place. There is an optional $1 fee to have your transaction be sent instantaneously. OriginStamp provide an online interface to verify your file, however in the event that the site goes down it is still possible as long as you have the master file of hashes for the day that you submitted your file. This can be downloaded from the site at the end of every day when the transaction takes place.
If you do not wish to sign the hash of your file onto the Bitcoin blockchain, you could use a third-party service. There are many services suited to this kind of use, including Archive.org and browser caching sites, such as Google Cache. You could also post the file to any social media site that has timestamping, however the integrity of these timestamps may be questionable as there is no cryptographic proof behind them.
When it comes to including these proofs with your file, the most recent block hash is easy. However, including the hash of the file signed into the blockchain is much more difficult. While it is technically possible for a file to contain its own hash, it is not realistically possible and would require a large amount of time (probably millions of years) and computing power to achieve. The best solution to this would be to predict the block number that your file hash will be signed into and include it in the file before signing. Ideally, this would be the current block number + 1, however if your transaction fee is too low or the network is congested, you might not make it in. If you are using Proof of Existence or a similar service, they provide an interface to search for hashes that have been signed using their service. Even if the service goes offline, you should still be able to find the transaction since the signature of the transaction is prefixed with some custom text in order to make it stand out.
An example use case for this kind of proof is when renting a house. When you first move in, it would be a good idea to take photographs all around the house clearly showing the current state and any existing damage. Put those photographs in a ZIP file and sign it using the method outlined, then you have cryptographically proven evidence of the state of the house when you first moved in. If any problems arise during your tenancy, you have evidence to back yourself up!