1
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.
Include checksum in a transaction
Answers
2
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.
how many bytes are md5 checksums or CRC data ? – CQM – 2014-07-31T13:47:43.573
MD5 under binary form is 128 bits or 16bytes long. A bitcoin address is 160 bits or 20 bytes long. – Jan Moritz – 2014-07-31T13:49:44.967
You can even add it under his hexadecimal form it will be 32 bytes long. – Jan Moritz – 2014-07-31T13:53:29.587
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 – 2014-07-31T14:47:09.513
Do you mean recovering the checksums from the transaction when you speak about "indexing"? – Jan Moritz – 2014-07-31T14:48:56.273
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 – 2014-07-31T15:06:29.493
A little bit like this transaction? (look at the bottom of the page there was a "DOCPROOF" added in the OP_RETURN)
– Jan Moritz – 2014-07-31T15:13:10.783Hmm, 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 – 2014-07-31T15:21:44.773
http://proofofexistence.com/ – Jan Moritz – 2014-07-31T15:26:17.910
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 – 2014-07-31T16:00:38.460
No you can't decode a hash but you can prove that at this moment the file existed. – Jan Moritz – 2014-07-31T16:07:36.017
btw, I thought OP_RETURN was decreased to 40 bytes – CQM – 2014-07-31T20:41:01.283
That is still enough for many hashing algorithm – Jan Moritz – 2014-07-31T21:21:15.450