I am working on iOS camera app and would like to store hash of photos inside blockchain for the "proof of existence".

AFAIK transaction with OP_RETURN in output has some disadvantages

• non-refundable. so every transaction burns coins and removes something from a finite resources. forever.
• can be rejected by miner/can be subject to reject because of low fee and negative impact of burning coins
• subject to change. OP_RETURN field used to be 80 bytes and has been changed to 40 bytes.

I appreciate any ideas

• I believe the OP_RETURN byte limit actually used to be 40 bytes and was increased to 80. May 26, 2015 at 14:02
• @StephenM347 it used to be 80 now it's 40 github.com/bitcoin/bitcoin/blob/0.10/src/script/standard.h May 26, 2015 at 14:19
• static const unsigned int MAX_OP_RETURN_RELAY = 40; May 26, 2015 at 14:20

For a proof of existence, you do not actually need to store the data in the blockchain. Merely commiting to it, by using its hash in way that is later provably used, is enough.

One such way is using a mechanism originally described as pay-to-contract.

Warning: elliptic curve math follows.

You start with any public key X (yours or someone elses). Then construct the modified key X' = (X + H(X || C)*G) [with H a hash function, || concatenation, and G the secp256k1 generator point], and send a transaction (possibly as part of an actual need to send money to X) to the address corresponding to X'. The receiver (which can be yourself if you do this for a change output) will need to add the value H(X || C) to his private key corresponding to X, to be able to spend the coins.

However, revealing X and C, plus the transaction in the blockchain you used to send to X', is a proof that C was actually known at the time of the transaction.

This scheme has the advantage of not requiring any data in the chain more than the transaction would already consume, and additionally that it is indistinguishable from a normal transaction, making it harder to censor or be subject to changing policy of nodes on the network.

An alternative possibly exists which works without modified addresses of transaction, but is not well studied yet.

• Do you happen to have a reference for the possible alternative you mentioned? May 11, 2015 at 15:02

One more possible way (and a predecessor of OP_RETURN) quote from Mastering Bitoin by Andreas M. Antonopoulos

Moreover, such transactions create UTXO that cannot be spent, using the destination bitcoin address as a free-form 20-byte field. Because the address is used for data, it doesn’t correspond to a private key and the resulting UTXO can never be spent; it’s a fake payment. This practice causes the size of the in-memory UTXO set to increase and these transactions that can never be spent are therefore never removed, forcing bitcoin nodes to carry these forever in RAM, which is far more expensive.

Regarding that quote it's possible to store data in address field and that's how OP_RETURN begins