<p>Yes you can. You can use OP_RETURN of course but there are also other ways, some "hacks" like adding an transaction output that refers to an Bitcoin address that instead of being the hash of your public key is the hash of your file.</p>

<p>Here is what Garvin Aderson said about OP_RETURN</p>

<blockquote>
  <p>Why 80 bytes? Because we imagine that most uses will be to hash some larger data (perhaps a contract of some sort) and then embed the hash plus maybe a little bit of metadata into the output. But it is not large enough to do something silly like embed images or tweets.
  Why allow any bytes at all? Because we can’t stop people from adding one or more ordinary-looking-but-unspendable outputs to their transactions to embed arbitrary data in the blockchain.
  What do I mean by “immediately prune-able?”  The form of the up-to-80-byte transaction output (“OP_RETURN ”) is such that it can never be used as an input for another transaction– so it can theoretically be forgotten by everybody except for machines that want to keep a full record of every single transaction (“archive nodes”). That is a big improvement over the various hacks people are using today to associate data with their transactions, and will be more important in the future when we implement code that saves disk space by keeping only unspent transaction outputs and not every old block.</p>
</blockquote>

<p>Source <a href="http://bitcoinexaminer.org/gavin-andresen-talks-about-the-0-9-release-what-is-finished-and-what-still-needs-to-be-done/" rel="nofollow">Gavin Andresen talks about the 0.9 release</a></p>

CC BY-SA 3.0
2014-07-31T13:47:43.573Z
how many bytes are md5 checksums or CRC data ?
CQM
CC BY-SA 3.0
2014-07-31T13:49:44.967Z
MD5 under binary form is 128 bits or 16bytes long. A bitcoin address is 160 bits or 20 bytes long.
Jan Moritz
CC BY-SA 3.0
2014-07-31T13:53:29.587Z
You can even add it under his hexadecimal form it will be 32 bytes long.
Jan Moritz
CC BY-SA 3.0
2014-07-31T14:47:09.513Z
is there a way to index all of this data, easily? I am trying to imagine a scenario where md5 data is associated WITH an address (only perhaps by an initial transaction signed or cosigned by a trusted source), I guess it is possible that those transaction's outputs can be aggregated on their own, and one could make a separate index of the transaction metadata
CQM
CC BY-SA 3.0
2014-07-31T14:48:56.273Z
Do you mean recovering the checksums from the transaction when you speak about "indexing"?
Jan Moritz
CC BY-SA 3.0
2014-07-31T15:06:29.493Z
Basically I am imagining a scenario where a file's checksum is associated with an address that a real person controls. But it is more important that the checksum is indexed than the address, and the person can prove the address (and checksum) is there's because they can sign the address. They would be the only one with this file. Kind of like how colored transactions work
CQM
CC BY-SA 3.0
2014-07-31T15:13:10.783Z
A little bit like [this transaction](https://blockchain.info/tx/8dd6356a635fb02f206346cfa1a465e9dd506c3a4148b1b01d65079b4cd3a190?show_adv=true)? (look at the bottom of the page there was a "DOCPROOF" added in the OP_RETURN)
Jan Moritz
CC BY-SA 3.0
2014-07-31T15:21:44.773Z
Hmm, that is interesting, so an address was created that then made a transaction to nowhere solely to create the OP_RETURN information? I hadn't considered that, but that is a nice possibility, retains the trustless aspect of having the data out there but in case of a hash of a file it should be able to be decoded by appropriate parties. How is this kind of transaction made?
CQM
CC BY-SA 3.0
2014-07-31T15:26:17.910Z
http://proofofexistence.com/
Jan Moritz
CC BY-SA 3.0
2014-07-31T16:00:38.460Z
great, so to clarify it wouldn't be possible to decode the file or even file name from that, but the holders of the file would be able to generate the same checksums at any point.
CQM
CC BY-SA 3.0
2014-07-31T16:07:36.017Z
No you can't decode a hash but you can prove that at this moment the file existed.
Jan Moritz
CC BY-SA 3.0
2014-07-31T20:41:01.283Z
btw, I thought OP_RETURN was decreased to 40 bytes
CQM
CC BY-SA 3.0
2014-07-31T21:21:15.450Z
That is still enough for many hashing algorithm
Jan Moritz
CC BY-SA 3.0
2014-07-31T13:43:08.183Z
2014-07-31T16:15:41.917Z
2014-07-31T16:15:41.917Z
Jan Moritz
<p>Is it possible to include a file's checksum in a transaction?</p>

<p>Not necessarily in Bitcoin's current blockchain due to the now limited OP_RETURN feature, but just in the blockchain/transaction concept in general.</p>

<transactions><blockchain>
Include checksum in a transaction
CQM
# Include checksum in a transaction

(Asked by: username_0 on 2014-07-31)

Is it possible to include a file's checksum in a transaction?

Not necessarily in Bitcoin's current blockchain due to the now limited OP\_RETURN feature, but just in the blockchain/transaction concept in general.

**Tags:** transactions, blockchain


---

## 1 answers

### Answer by username_1 on 2014-07-31. Score: 2 | Accepted answer

Yes you can. You can use OP\_RETURN of course but there are also other ways, some "hacks" like adding an transaction output that refers to an Bitcoin address that instead of being the hash of your public key is the hash of your file.

Here is what Garvin Aderson said about OP\_RETURN

> Why 80 bytes? Because we imagine that most uses will be to hash some larger data (perhaps a contract of some sort) and then embed the hash plus maybe a little bit of metadata into the output. But it is not large enough to do something silly like embed images or tweets.
> Why allow any bytes at all? Because we can’t stop people from adding one or more ordinary-looking-but-unspendable outputs to their transactions to embed arbitrary data in the blockchain.
> What do I mean by “immediately prune-able?” The form of the up-to-80-byte transaction output (“OP\_RETURN ”) is such that it can never be used as an input for another transaction– so it can theoretically be forgotten by everybody except for machines that want to keep a full record of every single transaction (“archive nodes”). That is a big improvement over the various hacks people are using today to associate data with their transactions, and will be more important in the future when we implement code that saves disk space by keeping only unspent transaction outputs and not every old block.

Source [Gavin Andresen talks about the 0.9 release](http://bitcoinexaminer.org/gavin-andresen-talks-about-the-0-9-release-what-is-finished-and-what-still-needs-to-be-done/)

> **Comments:**
> **username_0**: how many bytes are md5 checksums or CRC data ?  
> **username_1**: MD5 under binary form is 128 bits or 16bytes long. A bitcoin address is 160 bits or 20 bytes long.  
> **username_1**: You can even add it under his hexadecimal form it will be 32 bytes long.  
> **username_0**: is there a way to index all of this data, easily? I am trying to imagine a scenario where md5 data is associated WITH an address (only perhaps by an initial transaction signed or cosigned by a trusted source), I guess it is possible that those transaction's outputs can be aggregated on their own, and one could make a separate index of the transaction metadata  
> **username_1**: Do you mean recovering the checksums from the transaction when you speak about "indexing"?  
> **username_0**: Basically I am imagining a scenario where a file's checksum is associated with an address that a real person controls. But it is more important that the checksum is indexed than the address, and the person can prove the address (and checksum) is there's because they can sign the address. They would be the only one with this file. Kind of like how colored transactions work  
> **username_1**: A little bit like [this transaction](https://blockchain.info/tx/8dd6356a635fb02f206346cfa1a465e9dd506c3a4148b1b01d65079b4cd3a190?show_adv=true)? (look at the bottom of the page there was a "DOCPROOF" added in the OP_RETURN)  
> **username_0**: Hmm, that is interesting, so an address was created that then made a transaction to nowhere solely to create the OP_RETURN information? I hadn't considered that, but that is a nice possibility, retains the trustless aspect of having the data out there but in case of a hash of a file it should be able to be decoded by appropriate parties. How is this kind of transaction made?  
> **username_1**: http://proofofexistence.com/  
> **username_0**: great, so to clarify it wouldn't be possible to decode the file or even file name from that, but the holders of the file would be able to generate the same checksums at any point.  
> **username_1**: No you can't decode a hash but you can prove that at this moment the file existed.  
> **username_0**: btw, I thought OP_RETURN was decreased to 40 bytes  
> **username_1**: That is still enough for many hashing algorithm  

---

